esp: add support for the Espressif ESP32 chip #1289

aykevl · 2020-08-11T23:48:19Z

This PR adds very minimal ESP32 support. You can use it as follows:

tinygo build -o test.elf -target=esp32 -size=short examples/serial
esptool.py --chip=esp32 elf2image test.elf
esptool.py --chip=esp32 --port /dev/ttyUSB0 write_flash 0x1000 test.bin -ff 80m -fm dout

picocom --baud 115200 /dev/ttyUSB0  # optional

Support for other important things (GPIO control, tinygo flash, etc) can be added in later PRs. I've left them out to keep this as small and reviewable as possible, especially considering the LLVM branch switch.

aykevl · 2020-08-13T13:32:11Z

This is now ready for review.

igrr · 2020-08-15T06:37:59Z

.circleci/config.yml

+      variant:
+        type: string
+    steps:
+      # Cache the file because the Espressif download website is not particularly fast.


Another option is to download the same file from GitHub Releases, which should be pretty fast: https://github.com/espressif/crosstool-NG/releases/tag/esp-2020r2

Good idea, thanks!

I've updated the PR with this. That makes the CI file smaller and simpler (no caches needed).

igrr · 2020-08-15T06:47:48Z

targets/esp32.ld

+     * SRAM1 has other addresses as well but the datasheet seems to indicate
+     * these are aliases.
+     */
+    DRAM  (rw) : ORIGIN = 0x3FFAE000, LENGTH = 200K + 128K /* Internal SRAM 1 + 2 */


One thing to watch out for is that the startup stack is somewhere in that range. Might be useful to add an assert that the .data/.rodata sections don't overlap the stack used by the bootloader.

That's what gave me trouble initially. I solved it by setting the stack pointer at startup, see src/device/esp/esp32.S. That also makes the system more flexible, as it is no longer bound by the stack that was set by the boot ROM.

My point is that the ROM bootloader is using certain region as stack, and if the app's .data section happens to overlap the ROM bootloader stack, the bootloader will overwrite its own stack, while trying to load app's .data.

Right. I see. Thank you for explaining. In that case, I think there are two options:

Use the stack that is used by the ROM bootloader.

Let the application load .data instead of letting the ROM bootloader do that.

Is the bootloader stack documented somewhere?

PRO CPU stack is at 0x3ffe1320 — 0x3ffe3f20, and APP CPU stack is at 0x3ffe5230 — 0x3ffe7e30
(I think these values are defined somewhere in IDF, but I can't find the link right now. They can be extracted from the ROM code ELF file, provided at https://dl.espressif.com/dl/esp32_rom.elf.)

In addition to that there are .bss and .data sections used by various ROM functions, at
0x3ffe0000 — 0x3ffe0440, 0x3ffe3f20 — 0x3ffe4350, 0x3ffae000 — 0x3ffae6e0. If you do not plan to call ROM functions (other than stateless functions like memcpy and memset), and do not plan to call any libraries which in turn call ROM functions, you can ignore these other reserved regions.

On the ESP32-S2, the situation is a bit more sane, as the reserved regions are near the end of DRAM, and don't make "holes" in the continuous region you would otherwise use for the application.

Thanks, that is some great insight. Also thanks for the ROM file which will be useful. I will take a look and improve this PR accordingly.
It may be possible to use the given area for the heap anyway and block out the parts that are used by the ROM code. That shouldn't need any changes to the TinyGo heap. Although I'll probably ignore that for this PR and do that only when we actually want to call these special ROM functions.

On the ESP32-S2, the situation is a bit more sane, as the reserved regions are near the end of DRAM, and don't make "holes" in the continuous region you would otherwise use for the application.

Glad to hear! Unfortunately the ESP32 will be around for a while and we'll need to adjust to it somehow.

It may be possible to use the given area for the heap anyway and block out the parts that are used by the ROM code.

Right, that's what we do in IDF — these ROM stack regions are getting added to the heap allocator once the startup is complete. And the regions used for ROM .data/.bss are marked as reserved.

Unfortunately the ESP32 will be around for a while and we'll need to adjust to it somehow.

Of course, it was more of me saying that we realize that reserved regions in the middle of DRAM are tricky to work with, and in the subsequent chips the situation is somewhat improved.

aykevl

@igrr thanks a lot for checking this PR!

aykevl · 2020-08-15T13:06:28Z

targets/esp32.ld

+     * SRAM1 has other addresses as well but the datasheet seems to indicate
+     * these are aliases.
+     */
+    DRAM  (rw) : ORIGIN = 0x3FFAE000, LENGTH = 200K + 128K /* Internal SRAM 1 + 2 */


That's what gave me trouble initially. I solved it by setting the stack pointer at startup, see src/device/esp/esp32.S. That also makes the system more flexible, as it is no longer bound by the stack that was set by the boot ROM.

aykevl · 2020-08-15T13:07:08Z

.circleci/config.yml

+      variant:
+        type: string
+    steps:
+      # Cache the file because the Espressif download website is not particularly fast.


Good idea, thanks!

igrr · 2020-08-15T16:48:47Z

src/device/esp/esp32.S

+    .long _stack_top
+.global call_start_cpu0
+call_start_cpu0:
+    l32r a1, 1b


In Xtensa window ABI changing a1 like it is done here is not sufficient, i think. If any of the previous register windows contain registers not spilled onto the stack, these registers will get saved to their original frame locations, once the window overflow happens. This might not be a practical issue, unless the boot ROM stack overlaps with app's .bss and the window overflow happens after .bss is zeroed out. If that happens, some part of .bss will contain spilled registers.

To avoid this issue, disable WOE in PS register, set WINDOWBASE to 1 << WINDOWSTART, and re-enable WOE in PS. Here is the code snippet which does this: https://github.com/espressif/esp-idf/blob/c77c4ccf6c43ab09fd89e7c907bf5cf2a3499e3b/components/xtensa/include/xt_instr_macros.h#L26

aykevl · 2020-08-15T19:32:10Z

@igrr pointed out some flaws in the PR so I will mark this a draft again until I've fixed the issues.

aykevl · 2020-08-24T14:54:54Z

I think I've fixed all the issues pointed out by @igrr now. I'm still using a custom stack, but hopefully did the stack switch correctly this time. I've also added an assert to make sure the .data section won't overlap with the startup stack (although that should not normally happen in normal usage, with around 200kB for globals).

deadprogram · 2020-08-27T07:22:19Z

I think the only hesitation I still have is depending on the Xtensa fork of LLVM for everything, instead of using the official LLVM repo. Perhaps we should fork the Xtensa fork ourselves, and then use that dependency, just in case something else changes again. Not sure on that, perhaps I am just being over-careful?

I will find some of my ESP32 boards for some device level testing.

aykevl · 2020-08-27T20:05:34Z

Yes, good point. I have forked llvm-project into tinygo-org and pushed the branch and updated this PR accordingly, so that we have our own copy of LLVM (just to be on the safe side).

This is only very minimal support. More support (such as tinygo flash, or peripheral access) should be added in later commits, to keep this one focused. Importantly, this commit changes the LLVM repo from llvm/llvm-project to tinygo-org/llvm-project. This provides a little bit of versioning in case something changes in the Espressif fork. If we want to upgrade to LLVM 11 it's easy to switch back to llvm/llvm-project until Espressif has updated their fork.

deadprogram · 2020-08-30T21:28:19Z

Took a long time to build the LLVM. Also worth mentioning somewhere is you need to install the xtensa-esp32-elf-ld linker.

The program built the first time, and flashed/worked exactly as expected on my ESP32 board!

Seems like at this point we can merge this. We still have a lot of work to do to make it useful, but this is a massive step forward, and a long time in the making.

aykevl · 2020-08-30T22:33:29Z

Also worth mentioning somewhere is you need to install the xtensa-esp32-elf-ld linker.

Ah yes, forgot to mention that. Maybe I'll make a PR to Espressif one day to implement it in ld.lld, until then we need this dependency. However, note that you can in fact use the ESP8266 toolchain too (xtensa-lx106-elf-ld), but it seemed less confusing to me to just use the ESP32 version.

deadprogram · 2020-08-31T07:02:16Z

OK, merging. Incredible work @aykevl this is very exciting moment.

aykevl · 2020-08-31T10:40:56Z

Awesome! 🎉

andreisfr · 2020-09-25T11:58:10Z

Great job @aykevl !

aykevl force-pushed the esp32 branch 4 times, most recently from 70f91be to 95932ea Compare August 12, 2020 13:15

aykevl mentioned this pull request Aug 12, 2020

Add support for the ESP8266 #900

Merged

aykevl force-pushed the esp32 branch 9 times, most recently from 3089d5b to df56910 Compare August 13, 2020 12:59

aykevl marked this pull request as ready for review August 13, 2020 12:59

aykevl requested a review from deadprogram August 13, 2020 13:53

igrr reviewed Aug 15, 2020

View reviewed changes

aykevl commented Aug 15, 2020

View reviewed changes

aykevl force-pushed the esp32 branch 2 times, most recently from ffab466 to b4595f4 Compare August 15, 2020 13:17

igrr reviewed Aug 15, 2020

View reviewed changes

aykevl marked this pull request as draft August 15, 2020 19:32

deadprogram added this to the v0.15 milestone Aug 19, 2020

aykevl force-pushed the esp32 branch from b4595f4 to ff8570f Compare August 24, 2020 14:45

aykevl marked this pull request as ready for review August 24, 2020 14:54

aykevl force-pushed the esp32 branch from ff8570f to 258a466 Compare August 27, 2020 20:04

aykevl mentioned this pull request Aug 28, 2020

Flash ESP32 chips directly from TinyGo #1324

Merged

deadprogram force-pushed the esp32 branch from 258a466 to 36669a3 Compare August 30, 2020 19:17

deadprogram approved these changes Aug 30, 2020

View reviewed changes

deadprogram merged commit 3ee47a9 into dev Aug 31, 2020

deadprogram deleted the esp32 branch August 31, 2020 07:18

esp: add support for the Espressif ESP32 chip #1289

esp: add support for the Espressif ESP32 chip #1289

Uh oh!

Conversation

aykevl commented Aug 11, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

aykevl commented Aug 13, 2020

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

igrr Aug 15, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

igrr Aug 15, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

aykevl left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

aykevl commented Aug 15, 2020

Uh oh!

aykevl commented Aug 24, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

deadprogram commented Aug 27, 2020

Uh oh!

aykevl commented Aug 27, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

deadprogram commented Aug 30, 2020

Uh oh!

aykevl commented Aug 30, 2020

Uh oh!

deadprogram commented Aug 31, 2020

Uh oh!

aykevl commented Aug 31, 2020

Uh oh!

andreisfr commented Sep 25, 2020

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

aykevl commented Aug 11, 2020 •

edited

Loading

igrr Aug 15, 2020 •

edited

Loading

igrr Aug 15, 2020 •

edited

Loading

aykevl commented Aug 24, 2020 •

edited

Loading

aykevl commented Aug 27, 2020 •

edited

Loading