On Wed, Oct 30, 2013 at 10:43 PM, Brandon Warhurst <[email protected]>wrote:
>
>
> On Oct 30, 2013, at 4:04 PM, Andreas Fritiofson <
> [email protected]> wrote:
>
>
> On Wed, Oct 30, 2013 at 9:26 PM, Brandon Warhurst <[email protected]>wrote:
>
> I typically use a python script for this (there was a libmpsse project
>> somewhere, and I added a little additional SPI support and it has python
>> bindings). However, it would be extraordinarily nice to be able to do this
>> directly through OpenOCD. I noticed that there are several commands for
>> adapters in general that get added during OpenOCD initialization, however,
>> since this feature isn't present in EVERY FTDI JTAG adapter, I wanted to be
>> able to add scriptable commands either through the interface script, or on
>> top of the FTDI code, but without polluting the FTDI code. This is where
>> the problem comes in:
>> Basically I have to open one port as an SPI interface temporarily, send
>> some commands then I'm set and can act like a simple FTDI JTAG.
>>
>
> Is it the same interface (FTDI channel) that is used for JTAG after setup,
> or is it one of the other three channels? Are there schematics available?
>
>
> It uses actually 2: port a & c, a as an SPI interface and C as bit bang.
> C controls the ability to use the SPI interface, and A allows me to change
> a resistor. I use the FT4232.
>
So a is not used for JTAG?
> 1) I don't see any way to really do what I need through the scripting
>> interface
>>
>
> That kind of low level access (MPSSE commands) is not exposed to the
> scripting interface. But you DO have full control over the FTDI GPIO pins,
> so if you're not going to transfer huge amount of data, you might be able
> to (slowly) bitbang the SPI commands using a series of ftdi_set_signal
> commands. You'd have to define all the required signals in the
> configuration file beforehand.
>
> Do you have an example?
>
See any ftdi interface config file and the help for ftdi_set_signal. It
probably wouldn't work unless the necessary pins were on the same interface
as the JTAG driver uses, though.
> Is there any way to do this WITHOUT having to add another "mostly
>> identical" JTAG driver? It is unbelievably convenient to just write a
>> script and have support for my adapter.
>>
>
> If the SPI traffic uses another interface, you might be able to create a
> kind of "proxy" driver that just intercepts the init, opens the SPI
> interface, does it's stuff using the mpsse layer, closes the interface and
> calls into the regular ftdi driver init. The rest of the adapter API would
> just forward to the ftdi driver. Actually, this could be doable even if the
> SPI and the JTAG interface are the same, although the bitbang solution
> would probably be nicer in that case.
>
> Maybe an example here too? I think I get the idea, but it would be nice
> to see how it would fit into the compile/link scheme so that I can
> intercept the init correctly.
>
See the attached file. You would need to change the ftdi_command_handlers
array in ftdi.c to non static and of course add the new file to Makefile.am
(next to ftdi.c) and also make OpenOCD aware of the new interface in
interfaces.c (next to ftdi_interface). Usage would be as simple as taking
the relevant ftdi interface config file and replacing "interface ftdi" with
"interface ftdi_proxy".
/Andreas
/***************************************************************************
* Copyright (C) 2013 by Andreas Fritiofson *
* [email protected] *
* *
* This program is free software; you can redistribute it and/or modify *
* it under the terms of the GNU General Public License as published by *
* the Free Software Foundation; either version 2 of the License, or *
* (at your option) any later version. *
* *
* This program is distributed in the hope that it will be useful, *
* but WITHOUT ANY WARRANTY; without even the implied warranty of *
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the *
* GNU General Public License for more details. *
* *
* You should have received a copy of the GNU General Public License *
* along with this program; if not, write to the *
* Free Software Foundation, Inc., *
* 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. *
***************************************************************************/
#ifdef HAVE_CONFIG_H
#include "config.h"
#endif
#include <jtag/interface.h>
extern struct jtag_interface ftdi_interface;
static uint16_t voltage;
static int ftdi_proxy_khz(int khz, int *jtag_speed)
{
return ftdi_interface.khz(khz, jtag_speed);
}
static int ftdi_proxy_speed_div(int speed, int *khz)
{
return ftdi_interface.speed_div(speed, khz);
}
static int ftdi_proxy_speed(int speed)
{
return ftdi_interface.speed(speed);
}
static int ftdi_proxy_execute_queue(void)
{
return ftdi_interface.execute_queue();
}
static int ftdi_proxy_init(void)
{
LOG_INFO("Setting target voltage to %d mV", voltage);
/* Do your stuff here */
return ftdi_interface.init();
}
static int ftdi_proxy_quit(void)
{
return ftdi_interface.quit();
}
COMMAND_HANDLER(handle_target_voltage_command)
{
if (CMD_ARGC < 1) {
return ERROR_COMMAND_SYNTAX_ERROR;
}
COMMAND_PARSE_NUMBER(u16, CMD_ARGV[0], voltage);
return ERROR_OK;
}
extern const struct command_registration ftdi_command_handlers[];
static const struct command_registration ftdi_proxy_command_handlers[] = {
{
.name = "target_voltage",
.mode = COMMAND_CONFIG,
.handler = handle_target_voltage_command,
.help = "Set the target I/O voltage",
.usage = "[voltage]",
},
{
.chain = ftdi_command_handlers,
},
COMMAND_REGISTRATION_DONE,
};
struct jtag_interface ftdi_proxy_interface = {
.name = "ftdi_proxy",
.supported = DEBUG_CAP_TMS_SEQ,
.commands = ftdi_proxy_command_handlers,
.transports = jtag_only,
.execute_queue = &ftdi_proxy_execute_queue,
.speed = &ftdi_proxy_speed,
.khz = &ftdi_proxy_khz,
.speed_div = &ftdi_proxy_speed_div,
.init = &ftdi_proxy_init,
.quit = &ftdi_proxy_quit,
};
------------------------------------------------------------------------------
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
_______________________________________________
OpenOCD-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openocd-devel
