Proxmark3 community

Research, development and trades concerning the powerful Proxmark3 device.

Remember; sharing is caring. Bring something back to the community.


"Learn the tools of the trade the hard way." +Fravia

You are not logged in.

Announcement

Time changes and with it the technology
Proxmark3 @ discord

Users of this forum, please be aware that information stored on this site is not private.

#1 2009-07-27 16:01:49

henryk
Contributor
Registered: 2009-07-27
Posts: 99

Flashing with OpenOCD

Moin,

Having acquired a new Proxmark3 I wanted to flash the latest firmware, including bootloader. The most convenient way for me to do that is using OpenOCD and an Amontex JTAGkey-Tiny. There are several troubles along the way which I'll describe here.

OpenOCD configuration

Recent OpenOCD versions (I'm using 0.2.0-in-development (2009-06-02-12:10) svn:2000) have a drastically different configuration style, compared to previous versions. It's now slightly more complex but much more flexible. The most important difference: The configuration is split into multiple sections, each covering a certain element (e.g. the JTAG interface being used, the board layout and external flashes, the processor and internal flashes) and each in its own file. These files are then sourced from the configuration file. The OpenOCD distribution already installs a library of commonly used JTAG adapters and embedded processors, so this is now (in the best case) much easier and shorter to use.

For my setup (Proxmark3 with AT91SAM7S256, JTAGkey-Tiny) the following configuration file is all that is needed:

source [find interface/jtagkey-tiny.cfg]

telnet_port 4444
gdb_port 3333

source [find target/sam7x256.cfg]
bootrom-merged.s19

The new OpenOCD version seems to be more obsessive compulsive about S19 files than its predecessors (from reading the Makefile I at least suspect that somebody has used OpenOCD to flash in the past). It requires that the checksums match, and it requires an end of block record. Both of these are not handled correctly by tools/merge-srec.pl. One important consequence: The published official bootrom-merged.s19 is broken. Shame on you! ;-)

In order to fix merge-srec.pl please apply this patch (or something similar, I'm not a perl programmer so this might be stylistically awkward):

Index: tools/merge-srec.pl
===================================================================
--- tools/merge-srec.pl (revision 142)
+++ tools/merge-srec.pl (working copy)
@@ -6,13 +6,19 @@
 
 while(<FLASH>) {
        print if /^S3/;
+       $EOF_record = $_ if /^S[789]/;
 }
 
 open(RAM, $ramFile) or die "$ramFile: $!\n";
 
 while(<RAM>) {
-       if(/^S3(..)(........)(.*)/) {
+       if(/^S3(..)(........)(.*)([0-9a-fA-F]{2})/) {
                $addr = sprintf('%08X', hex($2) - 0x00200000 + 0x200);
-               print "S3$1$addr$3\n";
+               $line = "$1$addr$3";
+               $checksum = 0;
+               $checksum += $_ foreach map(hex, unpack("a2"x40, $line));
+               print "S3$line", sprintf("%02X", ($checksum%256)^0xff ), "\n";
        }
 }
+
+print $EOF_record;

I could then rebuild bootrom/bootrom-merged.s19 and get something that I would actually be able to flash.

Using OpenOCD to flash

After putting the hardware together and powering it on you may connect to OpenOCD using telnet and do the actual flashing:

$ telnet localhost 4444
> halt
> # Save the original contents to original.bin, better safe than sorry
> dump_image original.bin 0x100000 0x40000 
dumped 262144 byte in 22.183287s
> # Clear the flash
> flash erase_sector 0 0 15                       
erased sectors 0 through 15 on flash bank 0 in 0.052006s
> # Flash the newly built bootloader
> flash write_image .../bootrom-merged.s19 0x100000
Padding image section 0 with 308 bytes
wrote 3660 byte from file .../bootrom-merged.s19 in 0.574996s (6.216076 kb/s)
> # Flash the FPGA image
> flash write_image .../fpgaimage.s19 0x100000                                                            
wrote 42100 byte from file .../fpgaimage.s19 in 5.886035s (6.984886 kb/s)
> # Flash the OS
> flash write_image .../osimage.s19 0x100000
wrote 35810 byte from file .../osimage.s19 in 5.015024s (6.973188 kb/s)

I have used the osimage and fpgaimage from the pm3-20090713-r52 release since the armsrc directory didn't immediately build for me. This remains to be a quest for another day.

Offline

#2 2009-07-28 02:50:17

d18c7db
Contributor
Registered: 2008-08-19
Posts: 292

Re: Flashing with OpenOCD

Thanks, I've added your perl changes to the code so it now creates a valid checksum and end block record. What kind of issues do you have with armsrc, it compiles OK under windows and possibly under linux too as no one else has mentioned anything.

Offline

#3 2009-07-28 03:11:27

henryk
Contributor
Registered: 2009-07-27
Posts: 99

Re: Flashing with OpenOCD

d18c7db wrote:

What kind of issues do you have with armsrc

None, now, thanks. It didn't immediately work since I didn't feel like installing Yet Another ARM Toolchain. I already had an ancient gnuarm 4.0.1 installed (which we used for OpenPICC before the dawn of time) and two versions of sourcery's arm toolchain (which we currently use for OpenPICC). Makefile.linux used the old gnuarm and the resulting binary seemed to behave strangely.

I really didn't spend any time debugging this, since after I built my LF antenna and wanted to get the new tune code in the firmware, I found that tools/install-gnuarm4.sh is really simple enough (apart from the odd warning about me not being root) so I went for it. Building with that toolchain and then flashing with linux/flasher works fine now.

Offline

#4 2009-08-14 16:08:04

ryan
Contributor
Registered: 2009-06-17
Posts: 36

Re: Flashing with OpenOCD

henryk,

Just wanted to say thanks for this writeup.  I just got an arm-usb-tiny jtag and got it working (in osx even!) much quicker after reading this post than I would have on my own.

Offline

Board footer

Powered by FluxBB