[idea] Put more libs in Thumb mode

[slurdge]

Especially, if we put:

    $(SRC_ISO14443a) \
    $(SRC_ISO14443b) \

in thumb mode, we gain a massive 10% of space in Flash. Thumb mode is not necessarily slower than ARM mode, and can even be faster. I would put most of the libraries in thumb mode (if there are any gains in Flash space) and selectively promote ARM function if needed, as is made with RAMFUNCs.

[iceman1001]

If there is downside, I can not see any reason not to. go go go!

[iceman1001]

lets see. hf 14a sniff

#db# Starting to sniff
#db# [!] blew circular buffer! | datalen 231
#db# maxDataLen=231, Uart.state=0, Uart.len=0
#db# traceLen=0, Uart.output[0]=00000000

this will trigger someone.. :)

[slurdge]

Maybe we need the RAMFUNCs to be in arm mode. Try adding this to RAMFUNC def:

#define RAMFUNC __attribute((long_call, section(".ramfunc"))) __attribute__((target("arm")))

[iceman1001]

Now my hf 14a sniff works :)

[iceman1001]

OSX complains about RAMFUNC aswell now. Wasn't that easy as keeping the old attribute. Must have something todo with the whole thumb

And PS3.4 is really slow. Running lf search on it makes it time out. Like its locked up.. same on my WSL....

[iceman1001]

Updated homebrew to use arm-none-eabi-* from QT4 2019, gives us a gcc v9.2.1
Now it shouldn't complain about that attribute.

[doegox]

yes it compiles fine https://travis-ci.org/github/RfidResearchGroup/proxmark3/builds/695937111

So now what's left is testing more the fw for broken functionalities. That's strange that lf search breaks only on WSL/PS. It runs fine here on Debian. Maybe ticks.c is too critical for thumb ?

[slurdge]

What's a PS3.4 ?

[doegox]

What's a PS3.4 ?

https://github.com/Gator96100/ProxSpace/releases

[doegox]

Note that bz2 needs probably to be removed from latest client/android/CMakeLists.txt and added to the app dependencies

[iceman1001]

Note that bz2 needs probably to be removed from latest client/android/CMakeLists.txt and added to the app dependencies

Was that suppose to be posted in this issue? You mean the hardnested cmake, right?

@slurdge PS34, short for ProxSpace v3.4 release. PS33, PS32 is the earlier versions.

Its when I run lf search twice the error is seen.
make clean; make -j; ./pm3-flash-all; ./pm3 -c 'lf sea; lf sea;' -i

[doegox]

Was that suppose to be posted in this issue? You mean the hardnested cmake, right?

The Android cmake. Yes I should have reported in the other issue. Meanwhile I fixed it.

[slurdge]

@iceman1001 works even with twice the search on my Linux Mint. Maybe it's something that doesn't work with the gcc of PS3.4

[iceman1001]

Yes, PS34 and my WSL setup doesn't work. Second call to lf search finds the values, but then locks up. Easy to think its working.

[slurdge]

WSL with Ubuntu works here. Maybe some weird interaction between the two ?

[iceman1001]

Odd, very odd. I flash both bootrom / fullimage. pulled latest from repo.

[iceman1001]

hm,, its the lf search that is taking forever to run. So slow. Can ticks.c become crasy from going arm -> thumb?

[monster1025]

define RAMFUNC __attribute((long_call, section(".ramfunc"))) attribute((target("arm")))

it is broking build on my macOS =) Latest master.

[-] CC start.c
In file included from start.c:18:0:
BigBuf.h:42:1: error: target attribute is not supported on this machine [-Werror=attributes]
 bool RAMFUNC LogTrace(const uint8_t *btBytes, uint16_t iLen, uint32_t timestamp_start, uint32_t timestamp_end, uint8_t *parity, bool readerToTag);
 ^
cc1: all warnings being treated as errors
make[1]: *** [obj/start.o] Error 1
make: *** [armsrc/all] Error 2

[doegox]

what is the version of your arm compiler ? homebrew recipe has been updated to upgrade the arm compiler

[monster1025]

Oh, thx! Compiler update is fixing build =)

[iceman1001]

So, we are running this since a few days back. My mysterious lf search bug seems to have resolved itself.

time to close?

[doegox]

yep, we can still open specific issues if probs are popping