libpgiod.so 2.6.0 causes core dump on ARMv6 #361
Comments
rdratlos
changed the title
|
Thanks for the detailed info. V2.6 was tested on PIs with ARMv7/8 processors (4 and 5 for instance), not on ARMv6 (Pi Zero 1), as far as I know. I will need to set up a test to check if I can reproduce this... |
FDelporte
changed the title
|
@rdratlos it would also be interesting to see what you get out of boardinfo logging, see https://www.pi4j.com/documentation/board-info/ |
@FDelporte |
|
@FDelporte This platform is still supported by Raspberry OS Bookworm as well as Zulu Java 11. Would be good to use a "modern" GPIO API and get rid of the deprecated Linux file system based access. |
|
After native build of GpioD libraries on the Pi Zero 1 (ARMv6) itself with hacked POM and build scripts, which force 64 bit ARM arch, we got a working libpgiod.so. autoContext() and subsequent off/on of the digital output worked. Seems that something goes wrong, when building the libraries using cross-compiler on the 64 bit production machine. Btw.: Native GPIO build on this slow PI has become inexpensive and works pretty fast. Nothing compared to the nightmare with LinuxFS native builds two years ago. |
|
Hi @rdratlos great to hear you could solve the problem and performance is a lot better! |
|
Hi @FDelporte, I fear that we have now working 32 bit libraries but broken 64bit libs. I have attached a zip with a 2.6.0 Maven cache, which contains all native libs build on the Pi Zero. Would be interesting to know, if the aarch64 libs work on later 64 bit Pi. |
|
I currently don't have much time to look into this. If you could send a PR, then i can look into integrating it. |
|
@eitch:
with hacked build script (see above) to enable ARMv6 builds everything works fine again.
the minimal example app crashes again with java.lang.UnsatisfiedLinkError error: If I rebuild the native library again or just overwrite the local Maven cache with the previous rebuild above, the minimal example works fine again. Downloading the native libraries from Maven repository and then uploading again seems to break things. Never experienced this with LinuxFS native libraries, which are too large to native build on a Pi Zero 1. |
|
I can confirm that this is an issue. I use my original Pi 1s for a lot of IoT work as they're powerful enough to do so. I think this is something worth investigating. How can I help? Perhaps the first thing to note is that the 32-bit Pi OS builds for v6 all the time, even on a Pi 4! Maybe that's our way forward. You don't need to build on a Pi 1 to be able to run on a Pi 1. |
|
Side info regarding supported JDK versions on ARMv6: a short time ago, I tried out all versions listed by SDKMAN, which "should" be compatible with ARMv6. Turns out only Azul Zulu 8 and 11 do really work. No newer versions, and no versions of Liberica. There are plans to re-introduce 32bit support in future versions of OpenJDK as these platforms are still used a lot and have some very specific use-cases. |
|
I think the solution is simpler than we think. However, I'm struggling to find the build commands for the 32-bit binary libraries. I suspect a simple Can someone point me to the location of the build image? |
|
@hackerjimbo This is the image: https://github.com/Pi4J/pi4j-docker |
|
I've got a suspicion that the solution is fairly simple, just horrible! The default architecture for the ubuntu 32-bit ARM seems to be v7. What I think it needs is to move it to v6, tell it that it has floating point and then tell it to not use the thumb instruction set! (That last took a long time to figure out). Those flags are: Without them compile code into assembler gives the first few lines as: With those flags we get: So all that needs to be done is to add those flags in when cross compiling and we're done! |
|
Well I'll be jiggered! It turns out that ubuntu on 32-bit ARM compiles to thumb mode by default! This happens to work on the v7+ Pies because the hardware supports it. However, that doesn't work on v6 because the thumb mode (1) doesn't have floating point. All 32-bit Pies operate in ARM mode not thumb mode. Backwards compatibility, don't you know… |
|
So, I hear you ask, how does the ARM processor know if it's in thumb or ARM mode? Well, thumb instructions are 16-bit and 2 byte aligned. ARM instructions are 32-bit and 4 byte aligned. So those crafty chaps in Cambridge used the bottom bit of the PC to determine the processor mode: 0 → ARM and 1 → thumb. Clever, but nasty! |
|
Status update: I successfully built the |
|
Pondering this there may be another issue. I would hope that the java 11 from OpenJDK for v7 is compatible API-wise with the Azul JDK 11, but what if it's not? I suspect we may need to supply a “patch” to modify the jar file so that it has v6/Azul I disagree with the comment above that Pi 0/1s don't have the CPU power. As I sit here now I have 2 Pi 1s and 2 Pi 0s in the room performing everything from CO₂ monitoring to a clock on a 128×64 LCD screen. The CPUs are barely used. |
|
Hey, I've got this exact issue after attempting to upgrade from an ancient version, 2.1.1, because that version that has issue #244 (can't open multiple serial/SPI), but it was only fixed in 2.6.0, which has the new Gpio provider that doesn't work on the Zero W. I'm pretty inexperienced when it comes to hacking the original code, right now I just use the dependency with Maven and I am unaware of how to do the build script modification that is mentioned earlier. Can anyone give me some pointers on how to do that (or, patch the fix from #244 into the older version, if that's easier than modifying the build scripts)? |
|
Sorry for the delay in responding, but I've been on holiday. I think I'm going to have to provide a patch for the pi4j jar. The only non-difficult way to build the libraries for Pi 0/1s is to build it on a 32-bit Raspberry Pi OS (though that doesn't have to be on a 0/1, you could build it on a 5 — but it must be 32-bit). I'll see what I can do. |
|
Well that was a long wait from me! However, I've just had Pi 2 die on me (odd fault, everything seems fine except that the USB appears to be dead) so I now need this is use a replacement 1B+ (which I have) rather than get a new 4/5 or reuse a needlessly power 3 that I want for something else. I plan to initially just patch Looking at |
|
So I tried building against the system version of libgpiod rather than the custom and old one pi4j uses. This seems to be a better idea as someone else maintains it. Is this a good idea? It didn't work, I ended up with an Thoughts? |
We wanted to migrate a project from a custom LinuxFS based GPIO digital output control implementation to the new Pi4J GpioD plugin. The reason was that LinuxFS native code uses deprecated kernel API functions. As all tests after update failed, we performed tests using the distributed Minimal Example and Pi4J v2.6.0 installed directly on Pi using Maven. All attempts failed with core dump (SIGILL fatal error) in native code and following error information:
System information:
Even though GpioD support was introduced with arrival of Raspberry Pi 5 we have not seen any information that other PIs are not supported.
Any help would be appreciated.
hs_err_pid6664.log
The text was updated successfully, but these errors were encountered: