• Registered: 2010-02-03
  • Posts: 23

Topic: Request help with a number of issues getting up and going.

I've been playing with the PM3 for a couple of days now and have run into several problems. Some I have overcome, some I have not, and some I have no idea what is going on. Here is a laundry list. Any help would be appreciated. Once I am comfortable that I am up and running, I plan to update the documents to help others. But some of the these are better taken care of by someone that understands the project code and structure and intent much better than I do, though if the answers are explained to me here I will be glad to do the legwork to update the documents.

=========================================
Issue #1 - Flashing a virgin PM3.
Issue #2 - Directory structure in manual out of date
Issue #3 - Does the root directory have to be called "C:\prox-dev" and what is the "ProxSpace" directory?
Issue #4 - Image binary in files/Flash directory way out of date
Issue #5 - Warnings during make
Issue #6 - Can't update the firmware
Issue #7 - Pushbutton on PM3 may not be working as intended, based on LED behavior.
Issue #8 - Running the PM3 section has out-of-date flashing instructions.
Issue #9 - Manual doesn't say how to get into the gui environment.
Issue #10 - What are the various prompts in the GUI?

=========================================
Issue #1 - Flashing a virgin PM3.
---------------------------------------------------

I know the present documentation states that if you don't already know everything involved in doing this that you shouldn't be doing this, but I don't really agree with this. I think there are plenty of people that may lack a couple pieces of knowledge to know exactly how to do this but are fully capable of doing it with a little bit of guidance. I'm willing to contribute to the manual some of that guidance based on my experience. What I did was use the SAM-ICE programmer and it went extremely easily, so I will write that up and add it, noting that it is not the cheapest way to go, but a very easy way to get there. As far as the existing documentation regarding flashing via the JTAG, it strikes me that the file in the HOW-TO section is missing a very key piece of information: it never indicated what hardware is being used. Reading between the lines, I have concluded that it is something called a "Wiggler" that is connected to the parallel port. I think it should be explicit on that point.

=========================================
Issue #2 - Directory structure in manual out of date
---------------------------------------------------

In following the steps in the manual for setting things up on a Windows box, there are some confusing points probably stemming from things simply getting out of date. I'm refering to the information on the page:

http://code.google.com/p/proxmark3/wiki … s_Platform

Under "Setting up Compile Environment", it says you should end up with three directories underneath the directory C:\prox-dev, one of which is called "proxmark", however, the directory in the zip file that gets downloaded is called "pm3-20090905-r216", which can make people wonder if they have the right file, it they are missing a directory, if they should rename this directory to "proxmark", or what. If a new convention has been adopted whereby the old "proxmark" directory is now named "pm3-<version_info>", then it might be woth putting a note to that effect in the manual.

=========================================
Issue #3 - Does the root directory have to be called "C:\prox-dev" and what is the "ProxSpace" directory?
---------------------------------------------------

The manual doesn't give any indication of where the "C:\prox-dev" directory is supposed to come from. I have the impression that since the top directory in the zip file is "ProxSpace", that this is/was the top directory. But which is it? Does it matter? I don't know which one is current.

Like lots of people, I don't like putting non-system files on the C: drive and prefer putting them on the D: drive. Usually, if a software installer allows me to specify a directory on another drive, then I can assume that it will actually work there. However, since all we are doing is extracting files from a zip archive, I have no idea whether that is the case here or not. More to the point, I have no idea whether making it work from a different root location is as simple as extracting the files to that different location, a simple edit to one or two files, or whether it would not be worth the effort to tackle it. The manual should address this -- and if the files must be located in "C:\prox-dev", then that's the way it is and a note to that affect is sufficient.

I'm sure someone will think, "well, you have all the source code files and therefore you can figure it out for yourself," or, "well, try putting them in a different place and see if it works." In my opinion, neither of these is reasonable. I am not going to search through someone else's code trying to identify all of the potential pathing issues and, likewise, even if I install it somewhere else and it seems to work there is no (reasonable) way for me to know that the first time I use a function a month from now that I won't run into a hardcoded path that the assumed would be the case.

=========================================
Issue #4 - Image binary in files/Flash directory way out of date
---------------------------------------------------

I used the binary file (prox_image.bin) in the zip folder 2007[1].08.27-openOCD-ebuller-proxmark3-files.zip and it appears to be about 2.5 years old. Since so much of the documentation makes references to major differences to the code and the Summer 2009 release, it would seem to make sense to make an updated prox_image.bin file available in the this directory.

Related to this, I am trying to update the boards to the current firmware and am having problems. I'll address those later.

=========================================
Issue #5 - Warnings during make
---------------------------------------------------

When I ran the 5makeall,bat file it appears to have complete successfully but did throw some warnings about not being able to locate the file "vc90.pdb". The implication was that this was related to debugging capabilities that would now not be available. However, I found this file in the "winsrc" directory with a new creation date. So are these warnings what should be expected, or should the make found this file and done something different than it did.

It didn't look like there were too many warnings during the make. It might be a good idea to take a snapshot of them and put in a "make warnings.txt" file and tell people that if they see these kinds of warnings then they can probably ignore them. I realize that different people may get different warnings, so maybe this isn't as good an idea as it sounds on the surface.

=========================================
Issue #6 - Can't update the firmware
---------------------------------------------------

In the section "Flashing the Bootloader", it says that the flash tool will inform us of the revision of the bootloader we are using (or at least if it is not sufficiently recent). How is it supposed to do this? Since the proximage.bin file I used is a couple years old, I assume it is not sufficiently recent. However, when I run:

prox bootrom ..\bootrom\obj\bootrom.s19

This is the response I get:

Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

C:\prox-dev\pm3-20090905-r216\cockpit>prox bootrom ..\bootrom\obj\bootrom.s19
ERROR: The process cannot access the file because it is being used by another pr
ocess.
Usage: ..\winsrc\prox gui
       ..\winsrc\prox offline
       ..\winsrc\prox areas file.s19
               Known areas are: bootrom fpga os

C:\prox-dev\pm3-20090905-r216\cockpit>

I get the same results no matter which area I try to flash.

I don't know what to make of this, particularly since I get the exact same error message when I run "prox gui" even though the "prox" window opens and appears to work (it claims it is connected to the device).

=========================================
Issue #7 - Pushbutton on PM3 may not be working as intended, based on LED behavior.
---------------------------------------------------

When I power up the PM3 via the USB, I get the LED sequence that is described in the manual for older firmware, namely: All LEDs light, then just the yellow, then the green in addition, then only the red off to the side, then all are off. However, it's my understanding that if I hold the pushbutton down (and keep it down) as I apply power that I should get a different behavior. I don't, I get the same pattern whether the button is held down or not, on all three of the boards I built.

Could this explain the failure to flash the updated firmware successfully?

=========================================
Issue #8 - Running the PM3 section has out-of-date flashing instructions.
---------------------------------------------------

http://code.google.com/p/proxmark3/wiki/RunningPM3

The instructions on how to upgrade the firmware contained here seem at odds with those in the "Compiling" section. Here, it says to use:
#prox load osimage.s19
I would recommend having a separate section devoted to flashing the PM3 and have all other sections refer to it as needed, so that there is only one source of information that needs to be kept up to date.

=========================================
Issue #9 - Manual doesn't say how to get into the gui environment.
---------------------------------------------------

The user is left to devine that they need to run "prox gui" in order to bring up the interactive environment. This is not at all obvious,

=========================================
Issue #10 - What are the various prompts in the GUI?
---------------------------------------------------
When I run the "version" command within the GUI I get the following:

#db# unknown command

If I just run "ver" I get this:

>> bad command 'ver'

This leads me to believe that the second one, perhaps indicatd by the ">>" prompt, is being generated by the host environment and the first, perhaps indicated by no prompt (or is #db# the prompt?) is a message being sent back by the PM3. I suspect this is just a matter of the firmware being too old to support the version command. But it would be nice if the manual gave a bit of an overview about the gui such as the significance of the different prompts.

=========================================

Thanks a lot for any info regarding any of these issues. Again, I am more than willing to use what I learn and try to improve the documentation.

  • iZsh
  • Member
  • Offline
  • Registered: 2010-01-02
  • Posts: 84

Re: Request help with a number of issues getting up and going.

I'm sorry, but most of what you've just written is outdated, so I really feel sorry, considering how constructive what you just posted was...

If you look at http://code.google.com/p/proxmark3/source/list you'll see there are currently a lot of activities and a general code overhaul.

For example, as for today (from couple of hours ago), the windows version doesn't compile a "prox.exe" binary anymore. But you'll now get what you get for Mac OS and linux: proxmark3.exe and flasher.exe

You'll also have the exact same command prompt when running proxmark3.exe.

Obviously, unless someone else update the documentation at the same time, it's hard to do the code overhaul and the documentation at the same time, since we analyze the issues as we go, and there are a lot of issues. At least on the maintainability side, which eventually reflects on the documentation as well.

The compilation procedure for the client should stabilize now though. (I committed a COMPILATION file in the client directory as well to give a few requirements).

The good news is that, now we have one code base for the three platform, he'll be easier in the future to document it, since we won't have special cases depending on which platform you are on (except the compilation procedure of course).

  • Registered: 2008-08-19
  • Posts: 291

Re: Request help with a number of issues getting up and going.

To add to iZsh's comments, I've updated the COMPILING file in the client directory with Windows specific instructions on setting up the MinGW compile environment in order to compile the client. It's hopefully step by step enough that inexperienced users can follow it, if not please speak up and as issues arise I will attempt to update the instructions.

Please let us be clear that MinGW is only used to compile the client, you need to set up another compiler (devkitARM) in order to compile the ARM code in bootrom and armsrc.

You will also see some worrisome but in fact inocuous messages during compilation, such as path not found and CreateProcess failed. The makefile calls a "uname" command which is not available in Windows, not sure what causes the path not found messages (make -n only shows me process_begin: CreateProcess(NULL, "", ...) failed.)

  • iZsh
  • Member
  • Offline
  • Registered: 2010-01-02
  • Posts: 84

Re: Request help with a number of issues getting up and going.

I'm using MSYS, and I don't have any error/warning messages. Since we're targeting for a multi-platform software, and we'll probably assume to have basic common tools around, I would advise installing at the standard procedure to prevent from future issues.

  • Registered: 2008-08-19
  • Posts: 291

Re: Request help with a number of issues getting up and going.

Updated the instructions, compile now goes smoothly.

  • Registered: 2010-02-03
  • Posts: 23

Re: Request help with a number of issues getting up and going.

Thanks for the quick responses. I don't have a problem with finding out that most of what I experienced is outdated, but I'm not sure how outdated it is. The information I was commenting on from the documentation was obtained from the documentation as I was writing the post only three hours ago; if it was out of date for the code and other stuff I downloaded yesterday, it will be even more outdated now.

I went and took a look at the link to the "source/list" page and while I clearly see a lot of activity, I don't see how it tells me what I need to do to get these boards working. I have a slow internet connection and it took hours to download the 30+MB Compile Environment zip file. If I have to download it again, fine. But it sounds like I will be using procedures from the documentation that are even less correct than what I used yesterday.

I also don't think it is safe to just assume that everyone has a certain set of "basic common tools" around. A lot of people that want to use the PM3 just want to do only that -- use it. They don't want to develop code for it, at least not at first. If they are not going to be able to simply download an executable (which, yes, I know is anethema to the open-source community, but consider that most of the major apps, such as SubCommander, off that as an option), and, instead, are going to have to install tens of megabytes of files in order to build an app that is only a few hundred kilobytes, then at least tell them what the "basic common tools" are that it is assumed that they have.

  • Registered: 2008-08-19
  • Posts: 291

Re: Request help with a number of issues getting up and going.

wbahn, there will be precompiled releases of stable code such as the Summer 2009 release, however if you absolutely must have the latest features, I'm affraid the only way is to compile the latest code yourself.

iZsh, I noticed after deleting and reinstalling MinGW, etc that my perl was gone (needed for the ARM side) so I installed perl-5.6.1_2-1-msys-1.0.11-bin (which required libcrypt as well), anyway the compile now fails because the version.c produced by mkversion.pl has an invalid string, basically $ctime now produces a line like this "%6$04i-%5$02i-%4$02i %3$02i:%2$02i:%1$02i".

Any ideas why this version of perl would do that?

  • Registered: 2008-08-19
  • Posts: 291

Re: Request help with a number of issues getting up and going.

The issue seems to be with sprintf, example code here:

#!/usr/bin/perl

$local_time = gmtime();

print "Local time = $local_time\n";
($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) = gmtime(time);
$year = $year + 1900;
print "Formated time = $mday/$mon/$year $hour:$min:$sec\n";

my @compiletime = gmtime();
my $ctime = sprintf("%6\$04i-%5\$02i-%4\$02i %3\$02i:%2\$02i:%1\$02i", @compiletime);

print "compiletime @compiletime\n";
print "ctime $ctime\n";

Outputs:

$ perl test.pl
Local time = Sun Feb 21 08:31:44 2010
Formated time = 21/1/2010 8:31:44
compiletime 44 31 8 21 1 110 0 51 0
ctime %6$04i-%5$02i-%4$02i %3$02i:%2$02i:%1$02i
  • From: UK
  • Registered: 2009-05-01
  • Posts: 180

Re: Request help with a number of issues getting up and going.

Nice work guys...

One small thing - it's still not clear from the distribution how one would get started. The README in the root directory is full of mis-information. I have just updated it to point at the devkitPro toolkit, but even that is not quite correct yet - we don't use the environment created by the devkit installation... Specifically:

  export DEVKITPRO=/opt/devkitpro
  export DEVKITARM=$DEVKITPRO/devkitARM

Instead, you need to add the devkitPro bin directory to your PATH, which is not mentioned on the devkitPro 'getting started'  page...

The README is also out of step with the new menu structure, but I can't easily fix/check that as my PM3 is now dead due to installing the images built with this new version...

Symptom is constant reboot loop... sad

adam@algroup.co.uk's Website

  • iZsh
  • Member
  • Offline
  • Registered: 2010-01-02
  • Posts: 84

Re: Request help with a number of issues getting up and going.

Sorry d18c7db, I won't be much help here, I don't know perl and I haven't tried to compile the arm side on Windows.

Adam: yes the general README should be updated (btw, it mentions you can use cygwin, did anyone try cygwin instead of mingw recently?). But yeah feel free to smile
By the way, with marcan we'll be doing a lot of code/documentation overhaul in the next few day/weeks, I'm working on the client side, he's working on the arm side. Hopefully things will improve soon...

wbahn I understand your frustration but you have to understand that the proxmark isn't just some "product" you can just buy and use (at least not at this stage unfortunately). For the moment, it's more or less a research tool, not really aimed at the general public.  I really wish it was more mature, that would allow me to focus on some real feature implementations (which is the reason I bought one initially) instead of a boring code overhaul smile

So for the moment as d18c7db said, you should probably use the Summer 2009 release. Why aren't you using it? (I'm not even sure where it is documented either if you ask me). If you need more recent features from it, then feel free to ask us question about where you are stucked, we'll try to guide you depending on what you need/want exactly.
We should update the documentation soon too, but you just happen to jump into the plate in the middle of a major overhaul (which was started 1-2month ago out of the same frustration that you currently have).

Last edited by iZsh (2010-02-21 13:30:24)

  • Registered: 2008-08-19
  • Posts: 291

Re: Request help with a number of issues getting up and going.

I don't know perl either, that string looks almost like a regexp, in any case I tested this on a pristine XP VM reinstalling every package from scratch and the behaviour is the same.

I think rather than waste a lot of time getting to the bottom of this, it would be easier to modify mkversion.pl to get around this issue so if there are no objections I will use the code "($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) = gmtime(time);" to extract the date/time and create $ctime, the net result should be the same on all platforms. Any objections?

  • iZsh
  • Member
  • Offline
  • Registered: 2010-01-02
  • Posts: 84

Re: Request help with a number of issues getting up and going.

I guess you could first ask henryk if he has any clue why it's broken since he wrote that code.

  • Registered: 2008-08-19
  • Posts: 291

Re: Request help with a number of issues getting up and going.

Nevermind, I sorted it. I tried Activestate Perl 5.10 which behaved OK in that respect but had some other issues, in the end I used a cygwin disto Perl 5.8.6 which seems to work OK. It's a minimal install, just the perl.exe and some dlls which is enough for what we use it currently.