-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Test on big-endian byte order #4710
Comments
@haukepetersen and I were jesting about this at the last Hack'n'ACK that RIOT is likely to fail on big-endian systems, since some drivers basically assume little-endianess if little-endian is required (i.e. IEEE 802.15.4 radios). In #4646 I tried to straighten some kinks, but I bet I did not find all of them. But as far as I know some of our processors have switchable endianess, so indeed it maybe a good idea to start with those. |
This would indeed be very interesting to see, though we would need to find a suitable big-endian platform to port RIOT to. As a fact we know, that many device drivers are not able to run on big-endian systems, as there is a lot of manual byte ordering for little endian implemented. So how about we look out for a suitable, easy-to-port big endian platform first?! |
Bump |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions. |
I think we should still try to do this. |
Today, all big-endian machines are found in museums only, rendering endianess-safety a purely academic issue. (Still, our code base looks quite endianess-safe.) IMO this can be closed as "WONTFIX", as the effort to set up toolchains and VMs to actually test on big endian systems is not worth the gain. We still do code review for endianess-safety, which hopefully catches most of the issues. And if and when big-endian system become relevant again, there will be means to actually test this and fix the instances that slipped through the code review. If anyone disagrees with closing this, feel free to re-open. |
Marked it accordingly ;-). |
It would be interesting to see an interoperability test between RIOT running on a big-endian CPU (e.g. PowerPC, Sparc, some MIPS) and RIOT running on a little-endian CPU (e.g. x86, most ARM), as well as other IPv6 systems.
This interoperability test could possibly detect if there are any places where the byte order conversion is wrongly chosen or missing.
As a starting point without any extra hardware: It is possible to emulate ppc and sparc in qemu and run RIOT native on top of a Linux installation in such a system.
The text was updated successfully, but these errors were encountered: