-
Notifications
You must be signed in to change notification settings - Fork 145
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
Endianness related errors and warnings while running avrdude -c '*/u'
on s390x
#1917
Comments
avrdude -c '*/u'
on s390xavrdude -c '*/u'
on s390x
I tend to think just ignore S390x as no one would probably use avrdude on an S390x machine. But maybe it is interesting to find the root cause. |
It will be the endianness of the machine. I noticed several places where the code relies on little-endian hosts, and added comments to that effect. We might want to make AVRDUDE become more general. Great to see that we can test on a s390x. Edit: Little prio, though, as it's involved, time-consuming and (currently) with little practical use. |
Closed as not-planned then. |
Would it make sense if the build aborted when it detects it is about to build avrdude for a non little endian system? |
Sounds like a good idea. |
No so sure if there are still relevant embedded Linux system which use big endian system.
|
From the above Wikipedia entry, the only problem is with SPARC. I guess we do not need to worry about it and we can drop the support. Any objections? But you mentioned that avrdude used to run okay on the Sun Sparc machine, right? |
Doesn't NetBSD run on just about anything which is Turing Complete? Let me come up with a build time check, and we will see which builds start failing, for big endian systems on which avrdude probably has not been tested on for a long time. |
avrdude -c '*/u'
on s390xavrdude -c '*/u'
on s390x
UltraSPARC is probably no longer of much interest for us (sadly). After Oracle buying Sun, they turned it into a sole high-price database server solution. (Sun also sold a number of lower-price devices.) AFAICT, PowerPC(64) might still be a relevant thing though these days that is commonly big-endian. In FreeBSD, it's a Tier2 platform (like RISC-V, 32-bit ARMv7, and right now also i386 – to be phased out). If it's possible to fix the build errors and warnings, I'd very much prefer that over dropping big-endian support. If the s390x helps us with regular builds, the better. ;-) |
Could we get a recent build log including the corresponding |
@dl8dtl Stock avrdude-8.0.tar.gz s390x scratch build: https://koji.fedoraproject.org/koji/taskinfo?taskID=123000005 https://koji.fedoraproject.org/koji/taskinfo?taskID=123000024 That build log contains the output of I have attached to this comment both
compressed with gzip for storage size and GitHub compatibility. |
Perhaps the qemu-s390x or qemu-mips64 or qemu-ppc64 or qemu-ppc-sparc64 system emulators could be helpful here with a Debian system image or something like that. |
Good point about PowerPC(64) for FreeBSD. Big Endian and Little Endian version are both offered but it seems to me Big Endian version is more popular. It is said that Linux on PPC64 now mostly use Little Endian now. As for legacy MacOS PPC64, last version is Mac OS X 10.5.8 Leopard released on August 13, 2009. So maybe it does not matter any more. Even macports says that it is not supported. |
NetBSD still lists PPC64, MIPS64 and SPARC64 as tier one support system. And it says both big endian (eb) and little endian (el) MIPS are supported. |
OpenBSD PPC64 and Sparc64 are probably big endian as well. |
https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/9.4_release_notes/architectures#architectures https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/8/html/8.10_release_notes/architectures
Benefits of expanding support to s390x processor architecture and big-endian format |
Building a package for Fedora implies not only the
x86_64
architecture, but alsos390x
.However, running
avrdude -c '*/u'
fails there (full build log at https://kojipkgs.fedoraproject.org//work/tasks/1593/122671593/build.log).I do not know whether this points to some portability problems in the avrdude sources which should be fixed in avrdude, or whether this just means I should not build for s390x at all.
It is obvious that nobody will use a mainframe to programm a microcontroller with, but building for that mainframe might still expose bugs in the sources. So here it is for you to draw some conclusions.
The text was updated successfully, but these errors were encountered: