Research, development and trades concerning the powerful Proxmark3 device!
You are not logged in. Please login or register.
Has anyone else looked into the possibility of porting the current firmware to an open-source low-footprint RTOS? FreeRTOS jumps out at me as having support for our chip (albeit not using GCC, but there are GCC-usng makefiles for other chips), but I'd be open to suggestions for another piece of code.
FreeRTOS supports the chip just fine, also with gcc, see the OpenPICC project which has FreeRTOS and the same AT91SAM7S*. FreeRTOS would address and/or ease some of the issues I brought up in http://www.proxmark.org/forum/post/2222/#p2222 but would require two or three significant changes:
Porting the current bootloader infrastructure over would require some work.
Most everything in FreeRTOS is interrupt based (most notably USB). Nothing in the current code is interrupt based.
Multi-tasking means that the current task can be preempted by the scheduler at any point in time. The current code base takes significant advantage from the current lack of interrupts in that bit-banging and other stuff execute under exactly repeatable and predictable circumstances. I can't even begin to tell you how much easier this makes some things.
Again, porting the current USB infrastructure would be some work. (Though that may have to be done anyway.)
The timing problem can be worked around by temporarily disabling interrupts, but that kind of counteracts the point in adding multi-tasking in the first place. Note though that I'm not against FreeRTOS, I'm just cautioning that it will probably be more work than just dropping in the OS and copying over the application code.
I'm currently busy with another project but wanted to look into solving the problems I mentioned in the other post some time next January, and if we're going to do some major remodeling, we might just as well take FreeRTOS into the list of changes. (And while I'm at it I'd like to break the USB protocol migrate the flash tool away from .s19 files.)
Since this will then be a longer operation, I'd suggest creating a branch in the SVN so that the current code base can stay stable and experience incremental additions that are usable without waiting for the new code base to become stable.
FreeRTOS supports the chip just fine, also with gcc, see the OpenPICC project which has FreeRTOS and the same AT91SAM7S*.
Ooh! Great minds and all, I suppose. 
FreeRTOS would address and/or ease some of the issues I brought up in http://www.proxmark.org/forum/post/2222/#p2222 but would require two or three significant changes:
Porting the current bootloader infrastructure over would require some work.
Do we even need to do this? I was thinking we'd leave the code in bootrom/ as-is and only "FreeRTOS"-ize the code in armsrc/.
Most everything in FreeRTOS is interrupt based (most notably USB). Nothing in the current code is interrupt based.
I saw this as being one of the greatest benefits (rewritten USB code)!
Multi-tasking means that the current task can be preempted by the scheduler at any point in time. The current code base takes significant advantage from the current lack of interrupts in that bit-banging and other stuff execute under exactly repeatable and predictable circumstances. I can't even begin to tell you how much easier this makes some things.
... and here is where my understanding of the code is weakest. As much as I understand FreeRTOS from a brief look-through of http://www.freertos.org/implementation/, we should be able to guarantee a certain frequency of ticks (or rather, we know the minimum duration of each task slot) and a certain number of slots per task per second... how much of the code requires timing that would have to fit within one timeslot, and how much of the code just requires constant (but coarser) timing?
The timing problem can be worked around by temporarily disabling interrupts, but that kind of counteracts the point in adding multi-tasking in the first place. Note though that I'm not against FreeRTOS, I'm just cautioning that it will probably be more work than just dropping in the OS and copying over the application code.
I fully understand that this is non-trivial, I was just trying to find a good way to start -- it sounds like starting with the OpenPICC code would be the best approach (as opposed to starting "from scratch" with the base FreeRTOS).
I'm currently busy with another project but wanted to look into solving the problems I mentioned in the other post some time next January, and if we're going to do some major remodeling, we might just as well take FreeRTOS into the list of changes. (And while I'm at it I'd like to break the USB protocol migrate the flash tool away from .s19 files.)
Since this will then be a longer operation, I'd suggest creating a branch in the SVN so that the current code base can stay stable and experience incremental additions that are usable without waiting for the new code base to become stable.
I don't actually have SVN access, anyway What would be the best code to get working first? Basic USB comms (without RF functionality)?
Hey all,
Currently I'm helping Tom with his Mikey card. For his device (based on the at91sam7s512) I'm working on a usb-driver based on a standard CDC interface. It seems not possible to install the libusb library on windows (64 bit editions), since the CDC (usb-serial-interface) is supported out of the box on Linux, MAC OS X and Windows, I think this would be useful.
When my test results provide a reasonable (IRQ/FIFO) based interface and driver I can port it within minutes to the proxmark.
The FreeRTOS has it's own USB support dev libs I understand, those could be used I guess, but for now my focus lays on researching the possibility to use a simple and clear native library that uses CDC.
Cheers,
Roel
Sure, standardizing on CDC would be a good idea ... and we can bolt-on support for sending larger amounts of data over bulk pipes (for clients that specifically request it).
I'm afraid I don't understand your statement about the FreeRTOS USB vs native USB issue, though -- it looks like FreeRTOS is under consideration for that mikeycard, as well? (http://code.google.com/p/mikeycard/wiki/ChooseRTOS)
(Wouldn't it be nice if we could merge these codebases? )
I have recently started redesigning the firmware code from scratch. I'm doing all of my work on the proxmark4 prototype d18c7db designed but all of the code should work at the old design excluding certain parts the old proxmark doesn't have (sdcard, LCD, joystick etc.).
Up until now I've ported (with some minor tweaks) the DFU bootloader from OpenPCD/OpenPICC (done by Harald Welte). Within the next few days I should wrap up the USB CDC part as well. Right now the proxmark happily sends through the virtual com port, but does not receive. I have to debug that some more.
This code has no old functionality whatsoever as I started from a blank slate. All of the USB code is interrupt-based so no more polling.
Powered by PunBB, supported by Informer Technologies, Inc.
Currently installed 3 official extensions. Copyright © 2003–2009 PunBB.