xtensa esp8266 toolchain on arm64v8 (aarch64) not working #1263
Labels
Comments
|
Thanks a lot for the great report! I've just fixed manifest. In other words, we will not have espressif8266 toolchain for aarch64. Need to contact Espressif team and ask them about toolchain for aarch64 |
|
@ivankravets Bummer, but ok, that's out of our control :( Though there is a quick fix for this without having a special aarch64 build of the toolchain. Most OSs that at the moment support arm64v8 also have 32-bit compatibility modes for armhf. I manually tested running the armhf toolchain on a arm64v8 system (HassOS on RPi 3 in this case) and it worked fine 🎉 Would it be possible to tag the linux_armhf builds also as linux_aarch64? |
|
@OttoWinter could you provide an output from your machine: |
|
@ivankravets systype is In my software, I actually ended up just patching the |
|
Actually, I don't understand why it works for you and does not for @lobradov. This is a current manifest: {
"description": "xtensa-gcc",
"name": "toolchain-xtensa",
"system": [
"linux_armv6l",
"linux_armv7l",
"linux_armv8l"
],
"url": "https://github.com./jcmvbkbc/gcc-xtensa",
"version": "1.40802.1"
}
So, we can add |
|
Hi @ivankravets , I spent some time looking more into this issue. I'm now no longer quite sure why my previous patch worked (as you said correctly, armhf is not in the manifest). However I now have a patch that is really working: With that aarch64 (or armv8l) builds work correctly and the toolchain runs too. I'm not quite sure what the difference is between armv8l and aarch64, but the armv8l toolchain appears to work for all aarch64 devices I have.
|
|
Done! Please run |
|
Not sure if this is the right issue to lodge this against (as I thought there was another ESP8266 arm/aarch issue but can't find it)... but on a pine64 Pinebook (aarch) with headmelted's vscode-oss, the toolchain appears to be correct (i.e. the code is all compiling), but falls over when trying to run esptool right at the end. I think it is a x86/x64 binary is downloaded instead of an armhf one. I deliberately deleted the tool-esptool folder so platformio had to re-download it when it ran a build... |
You mean this https://github.com./igrr/esptool-ck/releases Could someone compile v0.4.13 on aarch64 and share binary? I'll deploy to our CDN. Thanks! |
|
That's the one! I thought I'd seen a post where you'd requested the binary, but couldn't find it again to follow up on it. :( Thankfully, the need for the binary may be going away soon ... esp8266/Arduino#5635 I've compiled and tried in on my pinebook, seems to be working great. :) Binary is downloadable here : https://dl.bintray.com/pfeerick/aarch64/esptool Compile log: SHA256 PIO verbose compile and upload of simple blink test for NODEMCU board |
|
@pfeerick Done! Thank you very much!!! 👍 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
What kind of issue is this?
Configuration
Operating system:
Armbian on Orange Pi Prime (Ubuntu Xenial based):
PlatformIO Version (
platformio --version):Description of problem
While PlatformIO itself installs correctly and can initialize a project, it would seems that binaries pulled for arm64v8 (aarch64) are not actually made for this architecture, so they cause exceptions and dump core.
Would be great to have an option to build a toolchain on the spot, rather than pulling a precompiled one.
Steps to Reproduce
On Orange Pi Prime (or assumably any Armbian/aarch64 board):
This will pull the latest debian-slim container image, install python, pull PlatformIO and try to compile an empty test.ino sketch. Feel free to ignore docker specifics.
Actual Results
On arm64v8 (aarch64), docker build breaks at compiling test.ino:
Expected Results
On amd64 (x86_64), build is normal and goes like:
If problems with PlatformIO Build System:
The content of
platformio.ini:Source file to reproduce issue:
Additional info
The text was updated successfully, but these errors were encountered: