Hi, The xtensa architecture is gaining popularity through cheap and popular ESP8266 and ESP32 wifi enabled MCU with Arduino & maker community (xtensa-lx106-elf). It is also useful for ath9k-htc development and was requested here without answer AFAIK: https://lists.debian.org/debian-gcc/2016/08/msg00175.html A few links: http://www.esp8266.com/wiki/doku.php?id=toolchain https://launchpad.net/~germia/+archive/ubuntu/esp8266ex https://github.com/esp8266/esp8266-wiki/issues/26 It would be nice to have binutils and gcc-xtensa just like we have binutils-avr, gcc-avr, *-msp430 and a few other popular MCU cross development tools in debian. Sincerely, Laurent
non-linux ports are maintained by maintainers other than the Debian GCC maintainers. So it depends on people doing the packaging and updating ... Even when not being a maintainer, you can ask people to sponsor your packages. You have some options to maintain the toolchain: - either as done above (packages in the PPA), including all sources in a package, and then building different binary packages. In this case you have to remove the non DFSG files from the sources (e.g. GFDL docs licensed with ínvariant sections). - "empty" packages relying on the -source packages found in Debian, like done for mingw64. This way packages tend to stay more up to date. Hope this helps, Matthias
I've been looking at generating binutils + gcc packages based on the binutils-source + gcc-7-source packages for the xtensa-lx106 target (ESP8266). I have something that seems to be working, and I'm considering uploading them, but I don't think it's possible to build a single toolchain that will target the ESP8266, ESP32 + ath9k Xtensa variants. The xtensa-lx106 binary packages are turning out at about 20M between them; is there enough use that it would be worth having all 3 options present in Debian? J.
Hi Jonathan, Let me argue that yes, that would be a good idea. We have esptool in the archive. The esptool comes with a flasher_stub (https://sources.debian.org/src/esptool/2.5.0+dfsg-1/flasher_stub/). Presently it cannot be built, because the toolchain would be required for doing so. It needs the xtensa-lx106-elf and xtensa-esp32-elf toolchains. The open-ath9k-htc-firmware package presently builds an xtensa toolchain from gcc-7 sources during build https://sources.debian.org/src/open-ath9k-htc-firmware/1.4.0-97-g75b3e59+dfsg-1/debian/cross-toolchain.mk/ using --target xtensa-elf. Having separate binary packages could simplify the packaging of open-ath9k-htc-firmware. Maybe the ath9k toolchain is less relevant as most users will be using open-ath9k-htc-firmware or firmware-atheros. Those that need can quite easily produce the toolchain from the open-ath9k-htc-firmware source package. But given the rising popcon of esptool (~200 now), toolchains for ESP8266 and ESP32 seem sensible to me. Note that any practical use will also need esp-idf. In particular, the flasher_stub from esptool needs esp-idf. Do you have any plans for packaging esp-idf? Also moving to gcc-8-source seems in order. Helmut
Yeah, I've ended up having to use the non-packaged esptool on occasion because the flasher stub makes things easier. To answer the question you asked on IRC (you left before I could answer); I'm using the ESP8266 toolchain built from the pkg-electronics git repo myself, with the esp-open-sdk and no problems. However I got the ESP32 toolchain built and had problems getting it integrated with the esp-idf SDK; various issues with not finding the system includes. I'm sure it's a matter of fighting with the build system a bit more, but I'm just getting started with the ESP32 so haven't investigated further. The ESP8266 is of much greater interest to me. I'm a bit torn about packaging the SDKs up, because they seem to be moving targets and aren't as relevant from the Debian side of things. So I have no immediate plans to do so, though I had some conversations with Keith Packard about at least getting newlib/nano support for the ESP chips into Debian. I've had this on my todo for a while, just not got round to it yet. J.
I filed Bug#917546 (binutils-xtensa-lx106) and Bug#917547 (gcc-xtensa-lx106) this week and both packages are now sitting in NEW. They target only the lx106 (ESP8266) Xtensa variant, but will hopefully be useful to others. I think this RFP should remain open, as long term it would be good to have a single Xtensa toolchain that is runtime configurable for multiple platforms. J.
Hello, This bug may be the wrong place to raise this issue, but what is the status of gcc targetting ESP32 in Debian?
Control: block -1 by 868895 isn't "just" a JSON data file that has been accidentally omitted from the package. It's in fact a (JSON-wrapped) binary, compiled from C sources bundled with the esptool source (and built with gcc, and a libc and everything). So it's not a matter of including the file, but rather rebuilding it. A lot of work has happened in Debian and with upstream over the years to build these binaries from unmodified sources, which culminated with Debian shipping the stubs for the ESP8266, as well as for the ESP32 RISC-V variants (ESP32-C2, ESP32-C3, ESP32-C6, ESP32-H2). See the 4.5.1+dfsg-0.1 and 4.6.2+dfsg-0.1 changelog entries, Debian bug #948096, as well as upstream issues #458, #499 and PRs #500, #501, #856, #858. The reason that the same has not happened yet for the ESP32, ESP32-S2 and ESP32-S3 stubs is that we lack the toolchain for them in Debian (gcc, binutils & picolibc). picolibc seems to have gained ESP32 support upstream in 1.7.9, and Keith Packard is both upstream and the Debian maintainer for it, so I suppose it won't be too hard to persuade him. gcc and binutils are more complicated. #868895 provides some context, and Jonathan McDowell, who maintains gcc-xtensa-lx106 and binutils-xtensa-lx106, is aware of the need. I think there is more of a backstory there, but he has the details. Note that the ESP-IDF is thankfully *not* needed anymore (see upstream #458). As an alternative, we could probably ship these three stubs as built by upstream separately in non-free, but I wasn't motivated enough, and I was hoping we'd get the toolchain in Debian at some point. (I'm not even the maintainer for esptool. If you're interested, I'm sure Milan will appreciate the help!). Finally, note that the stub isn't always necessary. --no-stub should work for some, but not all, operations, sometimes at slower speeds. Hope this helps! Faidon
Hi all, I just want to drop the note here that with #1033911, LLVM support for Xtensa has landed in Debian and is now available with the default llvm toolchain. Maybe that helps for some applications.
When I originally ITPed the lx106/ESP8266 variants I got some strong pushback about how we should really have a unified gcc/binutils that would be able to cope with various Xtensa variants. That doesn't seem to have happened. Faidon has done some work on building multiple versions from a single source, and I've finally accepted this is a better situation for now than not having the support at all. As a first step I've renamed the source binutils-xtensa-lx106 package to binutils-xtensa. I've got some changes pulled in from Faidon's work that will then build an ESP32 binutils package (I don't have later devices to test with) that I'll look at uploading once the new source package clears NEW. GCC is a bit more complex; when I tried previously I had problems with ESP-IDF, and I don't think a version that doesn't allow building with the upstream SDK is useful. I'll have a further poke at that to see if I can figure out what was going wrong. J.