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? :smile: 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: https://github.com/arduino/listSerialPortsC/pull/10 https://github.com/arduino/astyle/pull/5 https://github.com/arduino/avrdude-build-script/pull/10 https://github.com/arduino/toolchain-avr/pull/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. https://github.com/swarren/Arduino/commit/83145583b7e91843dc2c099c8d4c4a8b512062a7

[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 :smile: ). I believe that Ubuntu 16.04 can be a good baseline for the AARCH64 port :wink:

[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 :smile:

[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 :wink:

[swarren]

Awesome:-) Build 71 runs for me after I remove all the armhf compatibility packages and rename the java directory, and the compilation of "Blink" succeeds. I don't have access to a board today to test download. Serial port enumeration and serial monitor appear to work (I could only test sending without an Arduino board).

It looks like arduinoOTA is still a 32-bit ELF file.

[swarren]

So can we make a release without the embedded Java, or switch the embedded Java to OpenJDK on Linux?

[facchinm]

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

[facchinm]

Latest beta build (75) doesn't ship with java anymore (for aarch64) so it should be safe to use out of the box :wink:

[castaway]

sub I bought my Gemini PDA (aarch64) mostly with the intention of using it for arduino, I was surprised not to find it supported. Thanks for taking this on.

Downloading the current 1.9.0 beta from the link above, and installing openjdk9 via aptitude, I get the follwing when running ./arduino:

gemini@localhost:/usr/src/arduino-PR-beta1.9-BUILD-78$ ./arduino Picked up JAVA_TOOL_OPTIONS: java.lang.ExceptionInInitializerError at processing.app.helpers.PreferencesMap.load(PreferencesMap.java:100) at processing.app.helpers.PreferencesMap.load(PreferencesMap.java:74) at processing.app.PreferencesData.init(PreferencesData.java:55) at processing.app.BaseNoGui.initParameters(BaseNoGui.java:883) at processing.app.Base.(Base.java:209) at processing.app.Base.main(Base.java:147) Caused by: java.lang.NumberFormatException: For input string: "9-D" at java.base/jdk.internal.math.FloatingDecimal.readJavaFormatString(FloatingDecimal.java:2054) at java.base/jdk.internal.math.FloatingDecimal.parseFloat(FloatingDecimal.java:122) at java.base/java.lang.Float.parseFloat(Float.java:455) at java.base/java.lang.Float.(Float.java:554) at processing.app.legacy.PApplet.(PApplet.java:38) ... 6 more

any ideas?

[swarren]

Can you run other Java applications OK? Perhaps you have some Java preferences saved, and deleting/renaming the directory they're stored in might help? (Sorry no idea what directory that is)

[castaway]

Good question, I haven't tried anything else yet, as I just installed it for this purpose, so there shouldn't be any other prefs or similar.

[castaway]

I installed "umlet", a uml diagram generator, via aptitude, which seems to be built on + require openhdk.. and it seems to run fine..

[facchinm]

Hi @castaway, Java9 is not yet supported since they change the version format (sigh) so all existing parsers are failing. Please install openjdk-8 and it should be fine

[castaway]

bingo! thanks!

[PaulStoffregen]

It's like a blast from the past, where the Linux version used to be a tech support nightmare due to differing avr-gcc and java on various Linux distros.

[ghost]

The beta version runs great on its own, but I need to install the SAMD board definitions to work with my device (a 9DoF Razor IMU M0) which unfortunately only work with 32-bit ARM architecture. Is there any workaround for board manager packages yet?

[PaulStoffregen]

Now that 1.8.6 is released, is there going to be an AARCH64 file for 1.8.6?

As I recall, with 32 bit ARM it was published on the downloads page as "experimental" for several releases.

[facchinm]

To make it available in master we need to merge https://github.com/arduino/Arduino/commit/b34e1d4410c61bcd083d8693a1362bad75212621 (which is now currently in beta). I'd wait to understand the java thing, in the meantime I can add a link under the Beta banner

[PaulStoffregen]

Ok then, maybe for 1.8.7? Or maybe wait until Oracle properly supports AARCH64?

While beta is better than nothing, as far as gaining adoption in the wider community, a proper non-beta release is necessary. Almost nobody takes beta seriously.

[PaulStoffregen]

Any chance AARCH64 will be possible as a regular download with the upcoming 1.8.7 release?

[facchinm]

It will be under "experimental" label as we did with plain arm32 build

[PaulStoffregen]

@facchinm - Would it be possible to put a AARCH64 hourly build on the website today? Or maybe post a release candidate here? I'm setting up my Jetson board again today. Could give an hourly or RC a try and check if everything is looking good for 1.8.7.

[facchinm]

@PaulStoffregen the hourly version should be up and running (also on https://www.arduino.cc/en/Main/Software). The direct url is http://downloads.arduino.cc/arduino-nightly-linuxaarch64.tar.xz

[PaulStoffregen]

Sorry about the delay... I'm looking at this now. Turns out I couldn't log in to the GUI, only via ssh. Fixed now, turned out to be this problem.

Running the nightly right now. Everything seems to work. I tested compiling, uploading and viewing the serial monitor with an Uno and a Duemilanove. The cdc_acm driver was missing. Users may have to use these instructions to install it (and the command on that page is wrong, it's "./installCDCACM.sh", not "./installCDCACMModule.sh").

[PaulStoffregen]

Looks like Arduino Zero, the MKR boards, Arduino Due and Arduino 101 aren't yet supported. None of them can be installed from the Boards Manager.

[facchinm]

@PaulStoffregen I just moved the needed tools for samd_beta out of staging, this way at least samd boards are supported (there a bit of manual intervention needed though; the user must rename boards.txt.disabled into boards.txt and restart the IDE to have all the boards and not only MKRVidor). I'd say that, as a starting point, it can work. What do you think? Should we leave it in hourly but avoid an official release?

[PaulStoffregen]

It's going to say "experimental" on the download link, right? Since AVR boards are working well, I'd go with a release. Maybe later the word "experimental" could be turned into a link to this issue or a special page with tips for working around these limitations... if too many people get stuck.

[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.