Add support for the ESP8266

[aykevl]

To use this, use LLVM with Xtensa support:
https://github.com/espressif/llvm-project

Make sure you modify the CMake command (in the Makefile) to include the Xtensa backend:

-DLLVM_EXPERIMENTAL_TARGETS_TO_BUILD=AVR;Xtensa

You will also need to install the esp8266 GCC toolchain for the xtensa-lx106-elf-ld linker (lld doesn't yet support Xtensa).

I have used a NodeMCU dev board (clone?) to test this PR. Unfortunately, you can't yet flash it directly using tinygo flash, instead you have to use some esptool.py commands:

tinygo build -o image.elf -target=nodemcu examples/blinky1
esptool.py elf2image image.elf
esptool.py --port /dev/ttyUSB0 write_flash 0x00000 image.elf-0x00000.bin -ff 80m -fm dout

Many thanks to @cnlohr for the nosdk8266 project. That project helped me a lot to put together this minimal PR that avoids the SDK entirely.

[aykevl]

While this obviously doesn't work with the current builds, I think it would be nice to merge this. It allows interested people to experiment with this chip.

Afterwards, we may want to switch to the Espressif fork of LLVM (forked to the TinyGo org to be sure) so that this chip is fully supported in release builds.

[Hokutosei]

Got a bunch of excess 8266 around. It would be nice to try it, so +1 to this ＰＲ.

[kataras]

Interested to test it out, gj @aykevl

[aykevl]

For those wanting to try this out, the following steps should work (on macOS and Linux, also on Windows inside WSL). Mostly untested.

1. Get the TinyGo source.

   git clone --recursive --branch=esp8266 https://github.com/tinygo-org/tinygo.git
   cd tinygo
   

2. Modify the Makefile inside the tinygo directory a bit, replace -DLLVM_EXPERIMENTAL_TARGETS_TO_BUILD=AVR with -DLLVM_EXPERIMENTAL_TARGETS_TO_BUILD=AVR;Xtensa.

3. Inside the tinygo directory, download the Espressif fork of LLVM:

   git clone --branch xtensa_release_9.0.1 https://github.com/espressif/llvm-project.git
   

4. Build LLVM. This will usually take over an hour and require a significant amount of RAM (switch to Clang/ld.lld over GCC/ld.lld to speed it up a bit and reduce RAM requirements):

   make llvm-build
   

5. Build TinyGo:

   make
   

6. Test the build:

   ./build/tinygo build -o=image.elf -target=esp8266 examples/blinky1
   

7. You can also build a full release (stored in build/release.tar.gz):

   make release
   

[deadprogram]

So make release implies that the release build will not have any dependencies on an installed llvm? in other works, once merged will the next TinyGo release "just work" for tinygo build targeting esp8266?

I understand that we still need esptool for the flashing part.

[aykevl]

So make release implies that the release build will not have any dependencies on an installed llvm?

Correct.

in other works, once merged will the next TinyGo release "just work" for tinygo build targeting esp8266?

No. This branch only works when built with LLVM from Espressif. Therefore it won't work for release builds yet.
I could switch the default LLVM from upstream to the Espressif fork to get that to work:

tinygo/Makefile

Line 134 in 1d913a6

git clone -b release/9.x https://github.com/llvm/llvm-project

What do you think? Stick to upstream and require manually building LLVM, or switch to the Espressif fork?
I'm in favor of switching but thought it would be better to do that separate from this PR. However, I could definitely update this PR to switch to the Espressif fork if you agree.

[deadprogram]

This branch is 316 commits ahead, 21549 commits behind llvm:master.

Not sure we want to be completely dependent on the espressif fork of llvm.

Perhaps we could have our own build process for a separate espressif specific tinygo release build with the espressif fork of lvvm, until their changes get upstreamed. What do you think? Just seems like it is better to stay close to the mainline LLVM.

[aykevl]

This branch is 316 commits ahead, 21549 commits behind llvm:master.

Yes, because you're comparing against master (the development tree). This is the actual diff:

llvm/llvm-project@release/9.x...espressif:xtensa_release_9.0.1

EDIT: I checked and their branch is fully rebased on top of the 9.x release branch.

Perhaps we could have our own build process for a separate espressif specific tinygo release build with the espressif fork of lvvm, until their changes get upstreamed.

That is possible... but I don't really like that either. We currently have 6 binary releases for 3 OSes. Having special Xtensa releases would multiply that by 2, leading to 12 build artifacts (or fewer, but then not everyone has a prebuild binary).

Just seems like it is better to stay close to the mainline LLVM.

Yeah I agree, I don't really want to use a fork either. But their fork seems relatively clean and we might be able to rebase that on top of LLVM 10 once it gets released (effectively making a third fork ourself).

What about this: we switch to the Espressif fork now, but if it slows TinyGo down (Espressif doesn't update and we can't trivially rebase) then we switch back to upstream LLVM 10. If that happens, we can tell people that want to use the ESP chips to use an older TinyGo release and request Espressif to update their fork.

[deadprogram]

I checked and their branch is fully rebased on top of the 9.x release branch.

That is an encouraging sign.

Since we do not require LLVM install for our own release build, seems like your points about being able to switch back if needed are legit. And we all really want this functionality.

So now I am more in favor of merging this.

Anyone else have an opinion?

[yevsia]

So now I am more in favor of merging this.

+1

[bensinober]

I checked and their branch is fully rebased on top of the 9.x release branch.

That is an encouraging sign.

Since we do not require LLVM install for our own release build, seems like your points about being able to switch back if needed are legit. And we all really want this functionality.

So now I am more in favor of merging this.

Anyone else have an opinion?

+1
just tried it, compiles nicely against xtensa_release_9.0.1, builds esp8266 elf, and esptool pushes to esp8266 huzzah feather working!

Am really anxious to see this moved into release so we can push go on this beautiful little wifi devices!

[Durgaprasad-Budhwani]

+1 for merge

[niaow]

They do not seem to have rebased on LLVM 10, so I don't think we can switch over to espressif's LLVM yet. espressif/llvm-project#18

[aykevl]

No, I was hoping that they'd quickly provide an updated fork, which would have allowed people willing to put in the effort to use the ESP8266 with TinyGo. Right now, that seems unlikely. And with all the work I've put in AVR support (to be included in LLVM 11) I would like to switch over quickly once it is released, further reducing the chance of having proper ESP8266 support.

[aykevl]

I've rebased the Xtensa fork on LLVM 10, pushed it to a new xtensa_release_10.x branch in our LLVM fork, and updated this PR to make use of it (and rebased the PR on top of the dev branch). With that, I got blinky1 to run again on an esp8266 chip.

I've converted this to a draft because I want to use the SVD files produced by the esp-rs project to share work. Right now it manually defines all registers, which is of course a lot of work to maintain.

[aykevl]

Updated to use the SVD file created by the esp-rs project. It depends on one patch to the SVD file: MabezDev/idf2svd#17

Next steps:

1. Wait for that patch to be merged.
2. Submit the SVD file to posborne/cmsis-svd (similar to SiFive-Community) and wait for it to be merged.
3. Create our own llvm-project fork and push the rebased Xtensa branch there that I created.
4. Update this PR to make use of all that. This PR will be ready for review then.

Afterwards, adding support for the esp32 should be very similar, with most of the work already done.

[aykevl]

Update: first patch got merged, now I have another patch to update the base SVD file: esp-rs/esp8266#2

[aykevl]

Reported two issues with the LLVM 10 branch of Xtensa to Espressif:

espressif/llvm-project#33
espressif/llvm-project#34

Both are required for full Xtensa support, although simple stuff (blinking LED etc) would be possible without it.

[aykevl]

Also see: cmsis-svd/cmsis-svd#110

I have a local branch that adds ESP32 support, perhaps it's better to get that up and running first as there seems to be more interest in the ESP32 than in the ESP8266. Also, the ESP32 is much more powerful.

[aykevl]

Here is a PR for ESP32 support: #1289
It's almost ready for review.

[aykevl]

This PR is almost ready, it depends on cmsis-svd/cmsis-svd#112.

[aykevl]

This is now ready for review (if all CI tests pass).

I have chosen to use the same linker as is used for the ESP32 (xtensa-esp32-elf-ld), this simplifies the CI and should work just as well as the ESP8266 linker (xtensa-lx106-elf-ld).

[deadprogram]

Wow, congratulations @aykevl this is a real achievement, so many months in the making. Now merging with great pleasure!

[aykevl]

I need to add, you can flash a board with a command like the following:

tinygo flash -target=nodemcu -port=/dev/ttyUSB0 examples/blinky1