Re: Remote Flashing w/ Window Client & OpenOCD

On Feb 27, 3:03 am, Dominic <Dominic.at.use...@xxxxxxx> wrote:
Hi,

linnix wrote:
The files (flash.c and stellaris.c) have been modified to support
loading hex file and flashing from target memory.

It seems that flash.c and stellaris.c are not enough for the changes you
made - flash_driver_t is defined in flash.h, and doesn't have a "mode"
member.

Yes, I didn't bother to post the .h, just add the .mode member to it.


The remaining task
is to figure out how to initiate it.

Since OpenOCD supports both GDB and Telnet servers,
we can use either option.

Option 1: Add "$f,<flash addr>,<sram addr>,<count>#XX" on GDB protocol

Option 2: Add "load <flash addr> from <sram add>" on Telnet protocol.

Please comment on the changes and vote for one (the other will have to
wait). Thanks.

Generally, I don't think it should be necessary to modify any of the flash
drivers to support remote downloads. Changes would be necessary to
implement the "flash from RAM" you mentioned, but I'm not sure why you need
that.

My remote client (on Window) first upload data into target sram, then
issue a command to flash it. Problem with existing code is that the
file must be on the server first.


I'm currently implementing a file I/O helper that takes care of accessing
the files to avoid having this in every subsystem separately. This could
easily be extended to handle HEX files and possibly ELF files, too.
If remote access is desired, adding [XYZ]Modem support to the telnet
interface might be a straight forward choice, but I'm not sure how
complicated these are.

Telnet interface is not as easy as GDB. Packet size and format are
easier to control in GDB, where Telnet can be anything. My Window
client already have GDB and I hate to add another protocol to it.


The new GDB 'f' packet would be more work, because as I understand it the
remote target would have to provide a XML file describing the memory map to
the GDB client.

No, the remote client dumps into the target memory directly.


We also have a mailing list for OpenOCD development athttps://lists.berlios.de/pipermail/openocd-development/where Magnus
Lundin, the developer of the Cortex-M3 support, is subscribed.

Best regards,

Dominic


.

Relevant Pages