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.
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.
I noticed today that the 256kb memory limit is almost reached now.
I can't add my desfire impl anymore without it complaining over the size. I guess since the /common/lfdemod.c was added it kind of made the osimage bigger.
What do we do about this issue?
I also raised an issue on GitHub, you can find it here: https://github.com/Proxmark/proxmark3/issues/83
Offline
a lot of additions lately have made the OS bigger. i'm sure there are many many optimizations that can be done in the code that can help.
i know the lfdemod.c specifically only has a few functions in it that are actually REQUIRED to be in the arm with the code to date. (for offline mode) most of the code could be moved off the arm into the client, but that removes the ability to then use the demods in offline mode in the future. ( i asked where to put the code before i started... )
it appears the lfdemod.c currently uses about 12kb of the arm (if my calcs are correct), certainly has room for optimization.
but it also appears in our current code on github has 47kb empty.
Offline
but it also appears in our current code on github has 47kb empty.
Yup. When I flashed the os last time it said "240 blocks" which is 120k. Then there are 96k reserved for the two FPGA images. Seems to be lot of space left. Where has it gone?
Offline
latest flash: fullimage:
fpga: 165blocks,
osimage: 292blocks,
Where the memory went, we have added a lot of code the last year.
But it could also have something to do with how we define some globals and memorylayouts in the ldscript.common file.
https://github.com/Proxmark/proxmark3/b … ipt.common
Current Memory layout
Bootroom - 0x2000 (8kb)
fpgaimages - 88kb
osimage - dedicated 160kb
Since I have one PM3 with 512kb, I change the limit from 256kb -> 512 in the above ldscript, and it works good for that device. And changed some parameters to the gcc " -fdata-sections -ffunction-sections"
If I don't use the "-fdata-sections -ffun.." gcc parameters, I get the error message you'll see in GitHub Issue.
Offline
iceman, are you using PIWI's mod for Felica?
changed compiler optimization from -Os (optimize for size) to -O2 (optimize for speed). This should help us to keep up with the timing requirements.
Offline
Yeah I do, I've changed to the -02
Last edited by iceman (2015-03-25 23:26:16)
Offline
This is included in my figure above. The change in compiler options made my os (this is including topaz, excluding the new lf commits) grow from 118 to 120k.
Offline
So iceman, your trying to add 40kb more code with your desfire code?
Last edited by marshmellow (2015-03-26 00:48:30)
Offline
I really don't think I am and still I'm the one with the problem. How do you measure it? Look at the object files? that would be too big. Doesn't add up.
The error message states something about fullimage .data section overflows into osimage.
Could be the different cryptos using a lot of arrays.
Last edited by iceman (2015-03-26 09:57:07)
Offline
I looked at the .map file in the armsrc/obj folder and looked at the memory assignments
Offline