lack of binaries for aarch64-linux-gnu

[idanre1]

Basic Infos

git://github.com/esp8266/Arduino/tools/get.py does not really support aarch64-linux-gnu.

Hardware

Hardware: ESP-01
Core Version: 2.4.0-rc2

Description

git://github.com/esp8266/Arduino/tools/get.py does not really support aarch64-linux-gnu.
I am using dragonboard 410c as a host with debian.
The OS is compiled for aarch64-linux-gnu.
the script does not recognize the os type as aarch64.
Also there are no binaries for this compilation under package/package_esp8266com_index.template.json

Settings in IDE

Issue exists in installation phase, didn't reached IDE phase yet

[devyte]

@idanre1 I could be wrong, but I don't think that is a platform that is widely used here. Feel free to propose a PR.

[idanre1]

Hi Maybe its trivial, but what is a PR? Idan Idan Regev

…

On Tue, Oct 24, 2017 at 7:31 AM, Develo ***@***.***> wrote: @idanre1 <https://github.com/idanre1> I could be wrong, but I don't think that is a platform that is widely used here. Feel free to propose a PR. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3745 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AZJDnprphrvLri75zB0-K29ykeeuaNRgks5svWg2gaJpZM4QB7yr> .

[vdeconinck]

PR = Pull Request : https://help.github.com/articles/about-pull-requests/

[devyte]

You can find tutorials online for github. An outline off the top of my head:

• Fork this repo
• create a branch within the fork
• clone locally
• make changes for your request above and commit to branch
• make the PR
• once merged, delete the branch

[igrr]

Adding binaries for aarch64 may be more involved than described above, by the way. Aside from this repo, need to update the build process in igrr/esptool-ck and igrr/mkspiffs to produce these aarch64 binaries. Also we don't have an Xtensa toolchain built for aarch64, so that needs to be built as well. It is probably worth doing at some point, for example when we update to a more recent GCC version.

…

On Wed, Oct 25, 2017, 22:16 Develo ***@***.***> wrote: You can find tutorials online for github. An outline off the top of my head: - Fork this repo - create a branch within the fork - clone locally - make changes for your request above and commit to branch - make the PR - once merged, delete the branch — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#3745 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEJceiCgKbGZ7xsaw1rCcJMjJWgqZbkEks5sv0LGgaJpZM4QB7yr> .

[idanre1]

Hi Ivan Thanks for the support. Before I opened the request I was thinking compiling this git on my own to aarch64 Then I also saw the dependencies of other repos and I thought I am missing something since the get.py do have code for aarch64. Maybe we can ask igrr to help with he's repos? Regards Idan Idan Regev On Thu, Oct 26, 2017 at 2:47 AM, Ivan Grokhotkov <[email protected]> wrote:

…

Adding binaries for aarch64 may be more involved than described above, by the way. Aside from this repo, need to update the build process in igrr/esptool-ck and igrr/mkspiffs to produce these aarch64 binaries. Also we don't have an Xtensa toolchain built for aarch64, so that needs to be built as well. It is probably worth doing at some point, for example when we update to a more recent GCC version. On Wed, Oct 25, 2017, 22:16 Develo ***@***.***> wrote: > You can find tutorials online for github. An outline off the top of my > head: > > - Fork this repo > - create a branch within the fork > - clone locally > - make changes for your request above and commit to branch > - make the PR > - once merged, delete the branch > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub > <#3745 (comment)>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/ AEJceiCgKbGZ7xsaw1rCcJMjJWgqZbkEks5sv0LGgaJpZM4QB7yr> > . > — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3745 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AZJDnrsRq5U7vJyjNvj2JHPJ49M_3M5hks5sv8iIgaJpZM4QB7yr> .

[lobradov]

Bump - any news on this front? I'm also interested in aarch64 - just got a bunch of Orange Pi Prime boards that I can't use...

[igrr]

FYI, I don't think any of the active contributors is working on this (or has hardware to test this). As mentioned above, making PRs to the relevant tool repositories (esptool-ck, mkspiffs) to support aarch64 builds can help a lot!

[devyte]

Previous comment is correct. No active developer works on aarch64.
I think the critical point is building the xtensa toolchain. Whoever picks that up could also help getting an updated toolchain for everyone else (i.e.: more recent gcc!).

[igrr]

I think I can do the "more recent GCC" part, but if someone can post the right configuration for a Canadian build for aarch64 with crosstool-NG (preferably in Docker), that will be a great step towards having aarch64 support. Same for arm (v6/v7), by the way.

[herrold]

I went looking for the board, as it was unfamiliar here. I find this, and leave it as an aide for future work

at Amazon

1. This DragonBoard 410C features Qualcomm Snapdragon 410 Processor and is compliant with 96Boards specification

2. 96Boards is a 32-bit and 64-bit arm open specification maintained by the linaro 96Boards group to serve the software/maker and embedded OEM communities

[idanre1]

Hi
I am very excited this topic interests more people 👍

For more info on dragonboard you can goto DB410c landing page: https://www.96boards.org/product/dragonboard410c/
You can flash the boards with a debian linux distributed by linaro team.
I own such a board and doing some IOT hobby development using it.

In my training I am a HW guy now a SW, but maybe the info below can help the experts:

The board can compile C,C++ out of the box with linaro distribution.
When I do apt-cache policy I see:
500 http://obs.linaro.org/linaro-overlay-stretch/Debian_9.0 ./ Packages
release o=obs://private/linaro-overlay-stretch/Debian_9.0,n=Debian_9.0,l=linaro-overlay-stretch,c=
origin obs.linaro.org
500 http://obs.linaro.org/qcom/stretch ./ Packages
release o=obs://private/qcom/stretch,n=stretch,l=qcom,c=
origin obs.linaro.org
500 http://deb.debian.org/debian stretch/non-free arm64 Packages
release v=9.2,o=Debian,a=stable,n=stretch,l=Debian,c=non-free,b=arm64
origin deb.debian.org
using apt-cache search libgcc I get many GCCs compiled to aarch64

You mentioned docker, there are docker images for aarch64 at: https://hub.docker.com/u/aarch64/
I used the ubuntu image: sudo docker run -it aarch64/ubuntu /bin/bash

You also mentioned cross compile to aarch64, linaro posted a tutorial for doing it from a x86 linux machine: https://www.96boards.org/blog/cross-compile-files-x86-linux-to-96boards/

Given that, I still lack much info in order to do the necessary tasks for enabling esp8266 compilation for aarch64.

Regards
Idan

[herrold]

@idanre1

The topic is interesting in several ways, but as others implied, getting a cross build platform is the focus here, rather than generally using the SOC -- system on chip -- boards

I have several of the small ARM based units, and as you point out Ambian and other distributions exist. It is generally held (I disagree, as I started in a different era, compiling for the M6800 on a s/370 mainframe) that cross-compiling to a target architecture is less 'good' than 'naively compiling'

There are more widely used (Raspberry Pi), or less expensive (Orange Pi) SOC's around to also approach this goal -- the unit you cited has present and strong (it seems) IoT use case support with one of the 'biggies' behind it, and as I pointed out is available for purchase from a large distribution company as well

But solving and documenting an updated GCC compile issue is the interest, I think, here

[lobradov]

I use Orange Pi Prime, that I got from Aliexpress: https://www.aliexpress.com/store/product/Orange-Pi-Prime-Development-Board-H5-Quad-core-Support-linux-and-android-Beyond-Raspberry-Pi-2/1553371_32803048527.html It's much cheaper than the board you suggested, but has questionable compliancy to standards. In either case, board "works for me" for all stuff that actually offer aarch64 binaries (Armbian, Alpine, standard Docker library...), and I'm able to build other stuff from source (./configure && make). If I knew how, I'd be able to rebuild whole toolchain on the boards I have, but, being new to the project, I'm not able to figure out where to start... Any pointers would be appreciated. PS: You can use Docker + Qemu multi-arch images to cross-compile for armv8 (aarch64). Example article describing how/what: http://www.ecliptik.com/Cross-Building-and-Running-Multi-Arch-Docker-Images/ Using this, you can automate build + publish process by TravisCI. I'm playing with that to provide "Manifest" Docker images for multiple architectures.

…

On 29 December 2017 at 21:46, Russ Herrold ***@***.***> wrote: I went looking for the board, as it was unfamiliar here. I find this, and leave it as an aide for future work at Amazon <https://www.amazon.com/DragonBoard-410C-IoT-Starter-powered/dp/B01GCPW37O> 1. This DragonBoard 410C features Qualcomm Snapdragon 410 Processor and is compliant with 96Boards specification 2. 96Boards is a 32-bit and 64-bit arm open specification maintained by the linaro 96Boards group to serve the software/maker and embedded OEM communities — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#3745 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AcWpOtawK2Kf7LkxOHNhIzWIC4S0Ovmwks5tFU-bgaJpZM4QB7yr> .

[lobradov]

You mentioned you don't have the board, so I guess both Idan and I rushed to provide pointers... But, indeed, topic is - having a fully functional esp8266/Arduino environment available for aarch64. Critical part is xtensa toolchain, and I'll go bother jcmvbkbc/gcc-xtensa. Ivan mentioned getting a newer GCC, so I assume you want to change something in the project (rebuilding GCC instead of pulling a compiled one?), but I didn't quite get what's the idea. What else is needed? Where should I start?

…

On 29 December 2017 at 23:23, Russ Herrold ***@***.***> wrote: @idanre1 <https://github.com/idanre1> The topic is interesting in several ways, but as others implied, getting a cross build platform is the focus here, rather than generally using the SOC -- system on chip -- boards I have several of the small ARM based units, and as you point out Ambian and other distributions exist. It is generally held (I disagree, as I started in a different era, compiling for the M6800 on a s/370 mainframe) that cross-compiling to a target architecture is less 'good' than 'naively compiling' There are more widely used (Raspberry Pi), or less expensive (Orange Pi) SOC's around to also approach this goal -- the unit you cited has present and strong (it seems) IoT use case support with one of the 'biggies' behind it, and as I pointed out is available for purchase from a large distribution company as well But solving and documenting an updated GCC compile issue is the interest, I think, here — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#3745 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AcWpOmfLwgqCo69t22lGZSgNc2EB7O7uks5tFWZygaJpZM4QB7yr> .

[swarren]

This bug relies/depends on arduino/Arduino#7302 (AArch64 support for the Arduino IDE itself).

[probonopd]

There is now an Arduino IDE for aarch64 beta available from the Arduino.cc download page. It runs well for me after having installed openjdk-8-jre and deleting the java directory that came with the Arduino IDE like this:

sudo apt install openjdk-8-jre
rm -rf Downloads/arduino-PR-beta1.9-BUILD-87/java

However esp8266 seems not to be available for aarch64 yet.

[devyte]

To be clear, there is no ongoing work by the currently active maintainers to port the core to aarch64, and there is no plan for it either. As a precursor, at the very least the toolchain must be ported first, so until that happens nothing will happen here.

[devyte]

The status of this has changed due to ongoing toolchain update work.

[earlephilhower]

Check out PR #5376 which has a toolchain compiled for aarch64. I can't do any testing, and I am not sure I got the arduino host type name right in the get.py json file, so any testing would be helpful to make it happen.

[earlephilhower]

Closed via #5376 .

[probonopd]

Thanks @earlephilhower. Does this mean that esp8266 is available for aarch64 now?

[earlephilhower]

I'm building aarch64 compiler/etc. now, but can't test. Give the git head a go (it's not yet an official release).