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
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.
Hello,
it's been a while...
I was preparing some code commits (and a few blog posts), especially on the fpga side, but unfortunately the new LF DSP features I'm adding wouldn't fit in the tiny-ass fpga the proxmark3 has. After a few days working on area optimization to fit the code, I'm being tired making my code ugly-looking doing so :-)
Thus, just to let you know, I'm going to change the code to dynamically and on-demand program the fpga bitstream (either the HF features or the LF features) from the ARM side whenever an HF (resp. LF) command is called. The rational being that it's very unlikely (correct me if I'm wrong) that one would need to interlace a lot between HF and LF commands. That way we'll have more fpga LUTs for either HF or LF features.
If you guy don't like this idea, I can fork the code on my github.
Let me know if you have any better suggestion or comments. I'm starting working on the change right now. Hopefully this is possible at all, I haven't looked at the fpga programming code from the bootrom yet.
I plan to have two bitstreams, one for LF and one for HF.
Then I'll hook the lf and hf commands prefix (luckily I made a hierarchy of them back in 2010 ;-) ) with a function which checks which bitstream is currently loaded and upload the proper bitstream if needed. I think that should work unless I'm overlooking something.
Ideally it would allow to load module bitstreams on demand, kind of instead switching them via mux on a single big imageloading them separately when needed.
Please keep in mind, it should not break current functionality and allow easy additions. I.e. i changed some stuff to do lf read and a new hf snoop in a single fpga module. Your new code should allow me to load this module (put in a separate image) on femand via some function i put in the arm sources of my commands.
Best!
enio: the code is committed, and I think I provide what you're asking for:
you can call FpgaDownloadAndGo(FPGA_BITSTREAM_HF); or FpgaDownloadAndGo(FPGA_BITSTREAM_LF); in your arm code. it will check which bitstream is currently configured and switch it if needed
It's still using muxing within a bitstream though. One bitstream being always 42kb, we can't have one bitstream for each module (the ARM's flash being only 256k). Otherwise that would require doing the bitstream configuration from the host instead of the ARM, and I don't really like that. Hence, you have a mux in the LF bitstream to select the passthru/edge-detect/adc read mode, and something alike for the HF bitstream.
Last edited by iZsh (2014-06-20 11:51:15)