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 2014-06-19 11:28:44
- iZsh
- Contributor
- Registered: 2010-01-02
- Posts: 95
arm/fpga changes
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.
Offline
#2 2014-06-19 17:02:23
- Enio
- Contributor
- Registered: 2013-09-24
- Posts: 175
Re: arm/fpga changes
I welcome such change. Can you update me on your exact plans how its supposed to work?
Offline
#3 2014-06-19 17:32:13
- iZsh
- Contributor
- Registered: 2010-01-02
- Posts: 95
Re: arm/fpga changes
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.
Offline
#4 2014-06-19 22:03:55
- charliex
- Contributor
- From: Los Angeles/Scotland
- Registered: 2010-08-05
- Posts: 70
- Website
Re: arm/fpga changes
i did the same thing for my board, so i can upload test fpga images, gonna put different images on the sdcard for ondemand loading.
Offline
#5 2014-06-19 22:37:26
- iZsh
- Contributor
- Registered: 2010-01-02
- Posts: 95
Re: arm/fpga changes
i did the same thing for my board, so i can upload test fpga images, gonna put different images on the sdcard for ondemand loading.
Where is your code?
I'm almost done with mine
Offline
#6 2014-06-20 00:02:52
- iZsh
- Contributor
- Registered: 2010-01-02
- Posts: 95
Re: arm/fpga changes
there it is
https://github.com/Proxmark/proxmark3/commit/7cc204bff881ce1d1833d8e93469f6bbba80c70e
Now that i have more room i'm going to be able to commit my LF DSP stuff ^^
Last edited by iZsh (2014-06-20 00:03:56)
Offline
#7 2014-06-20 03:34:11
- charliex
- Contributor
- From: Los Angeles/Scotland
- Registered: 2010-08-05
- Posts: 70
- Website
Re: arm/fpga changes
izsh, ours is a different FPGA and pinouts, also SDCARD. i dont have write commit on the github so its in our svn at 032.la
Last edited by charliex (2014-06-20 03:34:46)
Offline
#8 2014-06-20 09:29:19
- Enio
- Contributor
- Registered: 2013-09-24
- Posts: 175
Re: arm/fpga changes
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!
Offline
#9 2014-06-20 11:46:50
- iZsh
- Contributor
- Registered: 2010-01-02
- Posts: 95
Re: arm/fpga changes
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)
Offline
#10 2014-06-20 13:19:54
- Enio
- Contributor
- Registered: 2013-09-24
- Posts: 175
Re: arm/fpga changes
Ok that sounds good and easy to extend if needed. Nice work 
Offline
#11 2014-06-20 23:29:33
- charliex
- Contributor
- From: Los Angeles/Scotland
- Registered: 2010-08-05
- Posts: 70
- Website
Re: arm/fpga changes
the entropy of the bit file is around 1.5 it'll pack down pretty well. a lot of people have the 512 chip too
Offline