AArch64 (64-bit ARM support)

[swarren]

There are currently no 64-bit ARM (AArch64) binaries of the Arduino IDE available to download, and it doesn't quite build from source.

I have modified the source of the IDE and all binary dependencies so that it builds (at least on Ubuntu 16.04), and will eventually send pull requests for all the build script repos.

Question: How do we go about updating the tool downloads on arduino.cc so that the IDE build can pull in the binary dependencies? Will you run the build process for each dependency after the relevant pull requests are merged, or would you want me to supply the binaries (for corporate legal reasons, that would be painful for me). Do you have access to an AArch64 to run the builds (NVIDIA Jetson TX1/TX2, a Raspberry Pi with a non-default Linux distro, and probably a few other devices would work).

[facchinm]

Hi @swarren ,
right now AARCH64 support is not a top priority, mainly because installing libc 32bit compatibility layer should allow all binaries to run seamlessly (does it? 😄 I tested it on a NanoPi Neo 2, only some tools and not the full-fledged IDE, so something could be broken).
The main issue in merging all the needed PRs is, as you correctly noticed, the presence of binary tools that, on one hand, make the IDE buildable simply with JDK on any platform, but on the other make supporting a new platform quite a PITA.
If the 32bit compatibility layer is the only requirement I'd rather wait for the platform to gain traction (and the distros to start shipping pure 64bit images)

[PaulStoffregen]

FWIW, at least a few people have expressed interest to me in running on Jetson or Odroid which use 64 bit ARM. I always give them the same answer: I only support Arduino has published directly from Arduino.cc, and there isn't a 64 bit ARM version yet.

[facchinm]

@PaulStoffregen isn't installing libc:armhf enough? In this case, I'll push to support the platform asap, otherwise we can live a bit without the "proper" package.

[PaulStoffregen]

I honestly don't know. My past experience has been that command line programs work, but anything GUI-based tends to have a long list of complex library dependencies that makes me feel dizzy.

So far I personally don't own any ARM64 hardware. Maybe I'll get a Jetson or Odroid?

[swarren]

We (NVIDIA) have been shipping AArch64-only systems for a couple of years now; for us at least AArch64 is pretty real. This bug was filed in response to real issues seen by participants at the MakeMIT2018 hackathon; almost everyone who used a Jetson in their hack had an Arduino attached to their Jetson and wanted to run the Arduino IDE to program it, but had to fall back to a PC or Mac for that part.

Installing a 32-bit libc isn't enough. The primary issue here is that the 64-bit JVM cannot load a 32-bit shared-library, so the liblistserialports and astyle libraries won't load. I didn't attempt to use the command-line utilities standalone, but there's a good chance they rely on other libraries besides the C library and also won't run with just the 32-bit libc installed.

Note that I've done all the work required to get all the various components built and running on AArch64, and I'll send pull requests for that soon. I'm just waiting on legal review before I contribute patches to the Arduino project, since we haven't contributed before.

[PaulStoffregen]

Just a tiny bit off-topic... but wasn't there a one-time maker discount or special deal on Jetson TX2? The only ones I can find now are all $600+

[swarren]

I'll address Paul's comment via email.

[swarren]

The following pull requests implement almost everything:
arduino/listSerialPortsC#10
arduino/astyle#5
arduino/avrdude-build-script#10
arduino/toolchain-avr#49

For the IDE's serial monitor to work correctly, we'll also need to following bug fixed and a new release of JSSC pulled into the IDE tree:
https://github.com/scream3r/java-simple-serial-connector/issues/121
"Please support 64-bit ARM (AArch64)"
(Or we could create a patch version of that dependencie's source and build our own)

Once those are done and new binary dependencies uploaded, I'll modify the following to contain the correct SHAs etc. and send a pull request for that.
swarren@8314558

[swarren]

When the binary components in the Arduino IDE are built for AArch64, what AArch64 OS will they be compiled on? I ask because (a) I tested all my patches on an Ubuntu 16.04 system, although I imagine the build would work on other OSs, and (b) whatever OS is chosen will be the oldest OS that the IDE binary components can run on, due to the way glibc symbol versioning and ABI compatibiilty work.

I think for a new feature like AArch64 host support, it'd be fine to support Ubuntu 16.04 and newer as a baseline. This is also the OS that NVIDIA Jetson TX1/TX2 and the ODroid use by default. I believe if we build on Ubuntu 16.04, then the binaries would also run on the SuSe Leap release for Raspberry Pi.

[lobradov]

armbian could be an alternative. It's a Ubuntu/Debian derivate for various arm boards, and supports many aarch64 fruit pi boards which might be good alternative to expensive jetson stuff.

https://www.armbian.com/

[facchinm]

The baseline for the linux32/linux64/linuxarm builds is currently Debian7, which ships with a slightly older glibc compared with Ubuntu 12.04 (I know, we are talking about Stone Age software but it's still somehow used 😄 ).
I believe that Ubuntu 16.04 can be a good baseline for the AARCH64 port 😉

[PaulStoffregen]

Ubuntu 16.04 sounds good.

FWIW, several months I replaced most of Teensy's old & kludgey device detection code with libudev. Previously I had been using Ubuntu 10 as my baseline. I quickly discovered programs compiled on Ubuntu 10 & 12 link against libudev0, but all modern Linux distros are now shipping with libudev1. I had to switch to using Ubuntu 14.04 as my baseline for x86 and Raspbian 8 Jessie as my baseline for 32 bit ARM.

[PaulStoffregen]

Is there any progress on even an experimental build for AArch64? Even an unofficial 3rd party of the IDE?

I'm about to make a new release of my installer for Teensy. Have the Jetson board sitting here, still unopened. Would love to try adding experimental an AArch64 version.

[facchinm]

I'm starting to add the builds artefacts to downloads server later today or tomorrow, so hang tight 😄

[PaulStoffregen]

Working here on needed components. Building the ARM 2016q3 toolchain is making the fan on my Jetson spin for the first time. :-)

[facchinm]

Here's a (very rough) first alpha version of the aarch64 build https://downloads.arduino.cc/ide_beta/arduino-1.9.0-beta-linuxaarch64.tar.xz .
arduino-builder is exactly the one shipped with arm "standard" version, so libc compatibility packages should be temporarily installed with

sudo dpkg --add-architecture armhf
sudo apt-get install libc6:armhf libstdc++6:armhf

to avoid ctags crashing badly.

Also, the bundled Java JRE is crashing with java.awt.HeadlessException (I can't understand why, need to investigate). To avoid this, install openjdk from the repos and delete java folder.
Compilation and upload on AVR already works once CDC drivers are installed (I used https://github.com/jetsonhacks/installACMModule.git )

[swarren]

Note that if you install L4T r28.2 on your system, the CDC-ACM driver should already be present. That version was released in March, so won't be pre-installed on Jetson, except just maybe for very recent purchases.

https://developer.nvidia.com/embedded/linux-tegra-archive

[swarren]

Also, the bundled Java JRE is crashing with java.awt.HeadlessException

Is the bundled JRE still 32-bit too? If so, you probably need to install a ton of 32-bit compatibility graphics libraries so the JRE can support non-headless operation. Best to switch to a 64-bit JRE to avoid the need for any 32-bit libraries.

[PaulStoffregen]

I hit the headless problem earlier too, using the same ARM 64 bit JDK (copied to the java folder) which I had used to compile the IDE.

[facchinm]

The bundled jre should be 64 bit, hence my concern (I'm checking right now, maybe I did something wrong on the CI script)

Edit: confirmed, the bundled java executable reports as

arduino-PR-beta1.9-BUILD-69/java/bin/java: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, for GNU/Linux 3.7.0, BuildID[sha1]=2e8f5458032d438d80c635cdcbcd7a229bf2b65c, not stripped

Edit2: it looks like jvm provided by Oracle is headless, we need to fallback to openjdk anyway (easiest way could be not embedding jre at all)

[PaulStoffregen]

jvm provided by Oracle is headless

Maybe this is a sign it's too early to support 64 bit ARM?

I seem to recall in Arduino's pre-1.0 history the Linux version was a tech support nightmare due to so many differences from the Mac and Windows versions. Bundling the identical jvm & tools finally put an end to those dark days. Do we really want to go back there?

[swarren]

Yes, I guess Oracle's JREs seem to be headless only. However, OpenJDK appears to work fine. I'd suggest simply not packaging any JRE with Arduino (any build/architecture, on Linux at least); as best I can tell all the major distros already package it (I checked Ubuntu, Debian, SuSe, Fedora) and nearly all package the same version of openjdk8, so there are unlikely to be any compatibility/support issues; I imagine OpenJDK has moved on a lot in the 6-7 years since Arduino 1.0.

[swarren]

I ran into one problem with the beta release linked above. The ctags binary is still 32-bit and requires compatibility libraries installed. This prevents compilation for sketches from working. Even installing package libc6-armhf-cross didn't solve this. Can we convert everything to 64-bit to keep things simple?

EDIT: To make package libc6-armhf-cross work, /usr/arm-linux-gnueabihf/lib/ld-linux-armhf.so.3 mys be symlinked into /lib, and all 32-bit binaries must be run with LD_LIBRARY_PATH=/usr/arm-linux-gnueabihf/lib, or that path added to a file in /etc/ld.so.conf.d. I'm not sure why the package doesn't do that itself.

A quick invocation of find shows that all the following are still 32-bit:

:~/arduino-PR-beta1.9-BUILD-69$ find -type f | xargs file | grep 'ELF 32-bit'|grep -v -e Atmel -e 'unknown arch'
./tools-builder/ctags/5.8-arduino11/ctags:                                                                           ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 2.6.26, BuildID[sha1]=8f193dd9f3304ecb7377a760bb555c04f9adeed9, not stripped
./tools-builder/arduino-preprocessor/0.1.5/arduino-preprocessor:                                                     ELF 32-bit LSB executable, ARM, EABI5 version 1 (GNU/Linux), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 2.6.32, not stripped
./hardware/tools/avr/bin/arduinoOTA:                                                                                 ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, not stripped
./arduino-builder:                                                                                                                               ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, not stripped

[facchinm]

For 32bit binaries compatibility I simply had to install

sudo dpkg --add-architecture armhf
sudo apt-get install libc6:armhf libstdc++6:armhf

A version of pure arm64 arduino-builder was not ready yet at the time, but it will be in the near future (I'll update the image accordingly)

[swarren]

Yes, those instructions work (with apt update in between) for me.

Now I know why apt-file didn't find the package with the dynamic linker for me; I hadn't added the dpkg foreign architecture support.

[facchinm]

By the way, latest build (71) should be fully native (arduino-builder, ctags and arduino-preprocessor at least) . The link is the same 😉

[jboco]

Hello,
I am trying to install your version of arduino IDE on jetson tx2 using the procedure in this link : https://github.com/arduino/Arduino/wiki/Building-Arduino but I get this error when I do "ant run". I would appreciate any help. Thanks.

[PaulStoffregen]

Here's a link to the latest version, already built and ready to use.

https://www.arduino.cc/download_handler.php?f=/arduino-1.8.7-linuxaarch64.tar.xz

[facchinm]

@jboco make sure your JAVA_HOME environment variable is not pointing to Oracle JDK (which does only ship a headless version of Java runtime) but to OpenJDK8. We are still trying to solve this problem, thus the "experimental" label on the download page.

[swarren]

PATH as well as JAVA_HOME too, I think?

[PaulStoffregen]

Pretty sure "ant run" will not work on AARCH64, so you can't use those instructions exactly on Jetson (at least not until Oracle provides a normal Java runtime with GUI support).

You can use Oracle's JDK 8u171 to build the code. But you can't use Oracle's Java to actually run it.

Try running just "ant" (without "run"). Then "cd linux/work" to change to the directory where your freshly-built IDE is awaiting you. Type "ls -l" to check what's actually in that folder. There should NOT be a "java" folder. If there is, delete it with "rm -rf java". Then use "./arduino" to run it.

You will need to have the OpenJDK runtime installed to actually run the IDE. Type "sudo apt install openjdk-8-jre" to get it.

Hopefully these instructions help?

[jboco]

@PaulStoffregen , if I download the latest version in the link you provided, what would be the installation and run procedure. would it be as usual:
cd /opt/arduino/ then chmod +x install.sh and finally ./install.sh ?

[PaulStoffregen]

I just run it with "./arduino".

[jboco]

@PaulStoffregen for some reason, it still doesn't work.

[PaulStoffregen]

Looks like it's trying to use the Oracle JRE, not the OpenJDK JRE.

If you don't have the OpenJDK JRE installed, run "sudo apt install openjdk-8-jre" to get it.

If you do have it, well, you're going to have to figure out how to get it to use OpenJDK rather than Oracle. Maybe find and delete the Oracle stuff somehow. Sorry, I can't guide you with the exact commands. You're going to have to figure this out.

Best I can tell you is it definitely did run here on my Jetson TX2 boards. I'm sure it'll work on yours too, once you overcome this problem with the Oracle headless JRE.

But if anything, this really shows the necessity of bundling a compatible JRE with the IDE, rather than relying on whatever the system provides, so things "just work" for end users!

[facchinm]

@PaulStoffregen I was thinking about integrating this JVM instead than Oracle's, do you think it could work? https://adoptopenjdk.net/releases.html
Maybe we can start using it in beta channel to get a broader testing audience?

[swarren]

OpenJDK 8 is the JDK that's typically bundled with Linux distros, and it's what people have used to test this release, so bundling that version makes sense to me.

However, @facchinm didn't want to bundle OpenJDK in an earlier comment for some reason:

I'd try to avoid embedding openjdk, but a release without java at all is feasible.

Still, if you've changed your mind, I think it's a good way forward.

[PaulStoffregen]

I was thinking about integrating this JVM instead than Oracle's, do you think it could work? https://adoptopenjdk.net/releases.html

Nope, not looking good. Tried it just now on my Jetson TX2. The IDE crashes when I try to open the serial monitor, with this error:

/home/paul/arduino-1.8.7/java/bin/java: symbol lookup error: /home/paul/.jssc/linux/libjSSC-2.8_aarch64.so: undefined symbol: _Znwm

I was able to successfully upload to an Arduino Uno. I can also upload to Teensy and successfully open the serial monitor if using Teensy's native communication. But if I select Teensy from the Serial section of Port, same IDE crash as with Uno.

The IDE completely crashes. There's no Java exception thrown. The windows all disappear and that symbol lookup error ends up in the terminal window where I ran "./arduino".

For a little more detail, first I ran "sudo apt remove openjdk-8-jre openjdk-8-jre-headless". Then I tried to run the IDE, and sure enough I got "./arduino: line 35: java: command not found". Then I created a "java" folder. I extracted OpenJDK8_aarch64_Linux_jdk8u172-b11.tar.gz and copied the contents of its "jre" folder to the new "java" folder.

[PaulStoffregen]

It does seem to work if I copy the JRE from /usr/lib/jvm/java-8-openjdk-arm64/jre.

I tried this just now:

rm -rf java/
sudo apt install openjdk-8-jre
mkdir java
cp -r /usr/lib/jvm/java-8-openjdk-arm64/jre/* java
sudo apt remove openjdk-8-jre
sudo apt remove openjdk-8-jre-headless

The IDE seems to run fine. I was able to upload to Arduino Uno and then open the serial monitor and see a sketch printing. Teensy also works with the serial monitor, both Teensy's native method and the Serial way.

[PaulStoffregen]

Here's a copy of that java folder. If you'd like a quick and easy way to make an experimental 1.8.7 release for aarch64, I'd recommend just adding this.

https://www.pjrc.com/teensy/beta/java_folder_for_aarch64.tar.xz

[swarren]

If you run ldd /home/paul/.jssc/linux/libjSSC-2.8_aarch64.so, does the output reference libstdc++? If not, it probably needs to be rebuilt including -lstdc++ or something like that. It sounds like the required library isn't available when the .so file is loaded, hence the crash. If the .so is linked correctly so that it knows it requires the library, there shouldn't be a crash, hopefully.

Note the license for OpenJDK (I don't recall what it is, but I assume GPL). If you distribute binaries, you likely need to either distribute the source too, or at least provide an offer of the source that people can follow up on.

[PaulStoffregen]

ldd /home/paul/.jssc/linux/libjSSC-2.8_aarch64.so
    linux-vdso.so.1 =>  (0x0000007f95371000)
    libc.so.6 => /lib/aarch64-linux-gnu/libc.so.6 (0x0000007f951f8000)
    /lib/ld-linux-aarch64.so.1 (0x000000558609d000)

[PaulStoffregen]

for some reason, it still doesn't work.

@jboco - You need to run "sudo apt install openjdk-8-jre"

Or you can extract that file I just posted, so it creates a "java" folder inside your Downloads/arduino-1.8.7 folder.

[swarren]

Yes, libjSSC.so needs to be rebuilt; it depends on a variety of symbols:

0000000000000000       F *UND*	0000000000000000              tcflush@@GLIBC_2.17
0000000000000000         *UND*	0000000000000000              **_ZdlPv**
0000000000000000  w      *UND*	0000000000000000              _ITM_deregisterTMCloneTable
0000000000000000         *UND*	0000000000000000              **_Znam**
0000000000000000  w    F *UND*	0000000000000000              __cxa_finalize@@GLIBC_2.17
0000000000000000       F *UND*	0000000000000000              cfsetospeed@@GLIBC_2.17
0000000000000000       F *UND*	0000000000000000              tcgetattr@@GLIBC_2.17
0000000000000000       F *UND*	0000000000000000              open@@GLIBC_2.17
0000000000000000       F *UND*	0000000000000000              __stack_chk_fail@@GLIBC_2.17
0000000000000000       F *UND*	0000000000000000              close@@GLIBC_2.17
0000000000000000  w      *UND*	0000000000000000              __gmon_start__
0000000000000000       O *UND*	0000000000000000              __stack_chk_guard@@GLIBC_2.17
0000000000000000       F *UND*	0000000000000000              write@@GLIBC_2.17
0000000000000000       F *UND*	0000000000000000              nanosleep@@GLIBC_2.17
0000000000000000       F *UND*	0000000000000000              fcntl@@GLIBC_2.17
0000000000000000       F *UND*	0000000000000000              read@@GLIBC_2.17
0000000000000000       F *UND*	0000000000000000              tcsetattr@@GLIBC_2.17
0000000000000000  w      *UND*	0000000000000000              _Jv_RegisterClasses
0000000000000000       F *UND*	0000000000000000              select@@GLIBC_2.17
0000000000000000         *UND*	0000000000000000              **_Znwm**
0000000000000000       F *UND*	0000000000000000              cfsetispeed@@GLIBC_2.17
0000000000000000  w      *UND*	0000000000000000              _ITM_registerTMCloneTable
0000000000000000       F *UND*	0000000000000000              __errno_location@@GLIBC_2.17
0000000000000000       F *UND*	0000000000000000              ioctl@@GLIBC_2.17```

... some of which are implemented in the C++ library, but doesn't have a DT_NEEDED entry for the C++ library:

```[swarren@swarren-lx1 linux]$ readelf -d libjSSC-2.8_aarch64.so|grep NEEDED
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [ld-linux-aarch64.so.1]```

This is the same problem as:
https://github.com/scream3r/java-simple-serial-connector/issues/121#issuecomment-419741972

[swarren]

I should have mentioned two more things:

1. The other libjSSC*.so do depend on the C+++ library, for example:

$ readelf -d libjSSC-2.8_armhf.so 

Dynamic section at offset 0x222c contains 28 entries:
  Tag        Type                         Name/Value
 0x00000001 (NEEDED)                     Shared library: [libstdc++.so.6]
 0x00000001 (NEEDED)                     Shared library: [libm.so.6]
 0x00000001 (NEEDED)                     Shared library: [libgcc_s.so.1]
 0x00000001 (NEEDED)                     Shared library: [libc.so.6]

$ readelf -d libjSSC-2.8_x86_64.so 

Dynamic section at offset 0x2e10 contains 24 entries:
  Tag        Type                         Name/Value
 0x0000000000000001 (NEEDED)             Shared library: [libstdc++.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libm.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libgcc_s.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]

2. If the JDK/JRE just happens to have loaded the C++ library into memory for some other reason, libjSSC*.so will still work even if the required DT_NEEDED flag is missing. Different JDK/JRE versions might have different behaviour re: whether they do/don't happen to load this library, hence this might all work in some cases but not others.

[swarren]

Did libjSSC.so get rebuilt to solve the issue in the previous comment?

[vap0rtranz]

The IDE seems to run fine. I was able to upload to Arduino Uno and then open the serial monitor and see a sketch printing. Teensy also works with the serial monitor, both Teensy's native method and the Serial way.

+1. Just tried your pre-built aarch64 for v1.8.7 on ArchLinux with OpenJDK v8 and the IDE started up with default sketch.

I did notice some slowness. For example, loading the UI to the Libraries is taking forever ("forever" = 1min+). I'll go increase the JVM heap sizes to see if that helps.

[facchinm]

@swarren not yet, I'm a bit busy at the moment but I'll mark it as todo before 1.8.9 (so we can probably go official at this point).

[PaulStoffregen]

Just curious, will a known-good JRE be bundled with a non-beta 1.8.9 release?

[facchinm]

Yup, both hourly and beta are being bundled with adoptopenjdk