Big-endian arm is pretty rare -- it's basically a niche requirement for markets like embedded network hardware where there is a lot of pre-existing code that assumes big-endian because it used to be run on m68k or mips. Most network protocols are big-endian on the wire, so on a BE host if you forget a htons() or ntohs() call it all still works; auditing a legacy codebase for that kind of bug in order to port it to a LE host is painful. But any general-purpose-ish Arm system (intended for running Linux or Android or Windows) will be LE.
Fun fact: the optimized string library for the original ARM1176 raspberry pi had a bonkers implementation of memcmp() which used the SETEND insn to temporarily switch to bigendian, because on that core setend is only 1 cycle and it saved an insn or two later. (On newer cores setend is a lot more expensive and the trick doesn't work.)
Fun fact: the optimized string library for the original ARM1176 raspberry pi had a bonkers implementation of memcmp() which used the SETEND insn to temporarily switch to bigendian, because on that core setend is only 1 cycle and it saved an insn or two later. (On newer cores setend is a lot more expensive and the trick doesn't work.)