ESP32-C3 (RISC-V) port

[Harvie]

New RISC-V based wifi SoC called ESP32-C3 was announced https://www.espressif.com/en/news/ESP32_C3
Unlike the Bouffalo Lab MCUs ( #559 ) this might actually be easier to support, since it is expected to be supported by ESP-IDF just like the classic ESP32. Biggest change is that RISC-V toolchain will have to be used rather than Xtensa compiler. But that should not affect the C code too much.

I guess this will be nice match for Mongoose OS. As well as ticket to the RISC-V future for all of us.

https://www.espressif.com/sites/default/files/documentation/esp32-c3_datasheet_en.pdf

[rojer]

interesting. it looks like they reuse peripherals from ESP32, which is good.
i assume we can ignore the "world controller" at least initially, until we figure out what's up with it.
i guess, as long as they provide the toolchain, it shouldn't be too much of effort to support this thing.

[MichiW1]

Hi all,
I am very interested in using this new chip version. Seems to be a good alternative between esp8266-based and esp32 solutions, while adding BLE in a low price system. There is even a module "ESP32-C3F" available which is directly pin-compatible with common ESP-12F... so not even new PCB-layouting needed :-)
How is the plan of Mongoose to integrate this ESP32-C3 support which is already available in ESP-IDF?
Thanks a lot, Michael

[rojer]

defintiely should do it, unfortunately it's a pretty big change and i don't have the time right now...

[duncandrennan]

We've been developing on Mongoose is various ways and based on our roadmap use of the -C3 is critical. Is support for the -C3 something that we can help to work towards? I don't really know how the hardware layer of MOS works to support different chips. If you can point me in the right direction I'll do some work to investigate how to support it.

[rojer]

there isn't really a guide for adding a new platform, yet.
i'll try to put something together.
but the basic steps are: make sure we can flash the thing (changes to mos tool), package SDK and toolchain into a docker container (this may not be required, as we already ship esp-idf and toolchain), then add basic bits into https://github.com/cesanta/mongoose-os/tree/master/platforms these are UART and GPIO drivers, exception handler, clocking, any other init stuff to launch the mos event loop (task). then check various other peripheral drivers, sucha as I2C and SPI - these are libraries, they need platform-specific code.
in the case of C3 most of this will probably be shared with esp32 (emphasis on shared, not copied from!) but careful examintaion of differences is necessary.

we can also discuss contract work to add C3 support, reach out to me personally if interested.

[duncandrennan]

Thank you! I'll start taking a look at this - it will be good to get a better understanding of how MGOS and the ESP-IDF fit together.

[duncandrennan]

I've started working on the mos tool to get it flashing the device. The eFuse structure is different, so efuses.go needs to be different. I guess this means defining an entirely new --platform esp32c3 along with all the necessary bit & pieces?

[rojer]

yes, i think c3 is a big enough change to warrant a new platform

[duncandrennan]

Where do I look for information about how the stub_flasher's work?

[rojer]

code is the documentation :)
it's been a while since i touched it and it looks like code has been buried during some repo restructuring, but it can be found here: https://github.com/cesanta/mongoose-os/tree/f626b5113861634e9a4acc96bdb73de29ed8a4d0/common/platforms/esp32/stubs

[rojer]

there's also a script i used to build the stubs when working on them:
https://github.com/mongoose-os/mos/blob/master/cli/flash/esp32/genstubs.sh

this is dead code right now and needs to be revived.
i think C source should be checked in under https://github.com/mongoose-os/mos/tree/master/cli/flash/esp

[rojer]

i dug up the sources and checked them into the repo - mongoose-os/mos@7ec8632

you can now develop C stub code, then rebuild and test it with a single command.

[duncandrennan]

How do the mgos docker containers work? I see, for example, that https://hub.docker.com/r/mgos/esp32-build/tags contains what I assume is ESP-IDF v4.2 (with various releases).

ESP32-C3 requires ESP-IDF v4.3, but I assume the docker container specifically needs to sets up all the necessary flags/etc. to build for ESP32-C3 (e.g. to use the riscv32-esp-elf-gcc compiler).

I haven't worked with Docker (other than using it blindly) so it is a bit of a mystery as to how the build system works. I think I understand it conceptually, but not in an practical way that allows me to configure a new docker container for esp32c3 builds. Maybe the esp32 container is sufficient as long as it has ESP-IDF v4.3?

[duncandrennan]

cesanta/mongoose-os/#584 is my first step towards this - a docker container for ESP32-C3 builds with the riscv32-elf-gcc compiler.

I'm busy working on getting the bootloader stubs compiled - there are some things to resolve around the SPI flash API in the stubs.

[duncandrennan]

@rojer I'm busy trying to get the bootloader stub (in the mos tool) to compile for ESP32-C3. I think I've made some decent progress but I'm stumbling a bit with regards to the assembler in main().

I've pushed code to duncandrennan/mos@1aefe5b

I've worked around the ccount() calls to use the correct assembler for the riscv processor, but I'm not quite sure what is actually happening in main() with regards to the __asm volatile("movi a1, stack_end\n"); - are you able to give me a kick in the right direction?

[rojer]

assuming you refer to this.
stub_main clears the bss segment and sets a stack pointer to where the stack will be.
in xtensa abi, a1 register is the stack pointer, so we point it at an appropritaely sized area that will be our stack.
since we don't plan to return from stub_main, we don't bother preserving the previous value.
since the stack grows down, we need to point at the end of the memory region.
stack is the actual stack space and stack_end is a variable at the end of it.
it's a bit sloppy of us to expect that stack_end will always follow stack in memory as linker is under no such pbligation, but in practice this seems to hold.
back then my asm-fu was not as good, if i were writing this today i'd be more careful.

so, bootom line is: you need to figure out how stack works on RISC-V and what it takes to relocate it to the location of the stack variable.

[rojer]

this is the more correct variant.

[duncandrennan]

With regards to cesanta/mongoose-os/#584 what are the rom.bin/elf files and where do they come from (or how are they generated)?

[rojer]

rom.bin is the dump of ROM.
rom.elf is that same dump in ELF format, so it can be loaded into debugger.
these are just nice-to-haves for core dump debugging, don't worry about them for now.
if you don't have a rom dump for C3, delete both files for now.

[duncandrennan]

Espressif offers an ELF format file here, https://docs.espressif.com/projects/esp-idf/en/latest/esp32c3/api-guides/core_dump.html#rom-functions-in-backtraces but that .elf file is significantly bigger than the ESP32 rom.elf, and if I convert that to a BIN file with riscv32-esp-elf-objcopy it is 3.5MB versus the 0.5MB of the ESP32 rom.bin

[rojer]

as i said, don't worry about it for now.

[duncandrennan]

mongoose-os/mos#70 is the initial draft of the bootloader stub. It compiles, but definitely needs some checking

[duncandrennan]

I've made progress on getting this to read and write the flash correctly. Reading is working but I've struggled quite a bit with the writing. When I try to write to flash the device stops communicating. I've been able to hard code it to flash some data, but something with regards to the UART ISR for receiving the flash data is going wrong. I've had inconsistent behaviour over recompiles, so we're also double checking the placement in memory and stack requirements. Working on getting this resolved so that we can start working on getting the actual OS code compiled. I haven't had a proper debugging environment set up, so that is the next step for me. Hopefully I can do a PR with something that actually works shortly.

[duncandrennan]

@rojer Are you able to give me some pointers as to how to debug the bootloader code? I'm not quite sure whether to load the bootloader via gdb and then skip the mos stub loading steps, or let mos load the stub, then try to attach to it from gdb. If you have some guidance, that would be very helpful. Thank you!

[rojer]

hey Duncan, i plan to work on C3 port myself soon, i'll have a look myself at that point.

[duncandrennan]

@rojer got the flash reading & writing working on the ESP32-C3's

[rojer]

yes, and i intend to continue working on the port from here

[rojer]

a8db502

[rojer]

initial support is done. still TBD: eFuse and flash encryption support

[duncandrennan]

Wow! Thanks @rojer

[duncandrennan]

@rojer I tried to build our firmware using this with the "latest" mos and libraries, but it fails complaining that it doens't know about the esp32c3, only [esp32]. I looked through the mos code as AFAICT it scans through the modules/mongoose-os/platforms looking for sdk.version files then adds the directory name to the supported platforms. I do see the esp32 and esp32c3 directories in the platforms directory, so I'm not really sure why this is failing. Got the same result from a local or a remote build. I haven't tried rebuilding mos locally and using that. Exact error log (from remote build) is

rror: /src/cli/build_local.go:225: can't build for the platform esp32c3; supported platforms are: [esp32] (use --no-platform-check to override)
/src/cli/build.go:278:
/src/cli/build.go:143:
/src/cli/main.go:194: build failed
Error: /src/cli/build_remote.go:359: build failed
/src/cli/build.go:278:
/src/cli/build.go:221:
/src/cli/main.go:194: build failed

[duncandrennan]

Ok, figured out the issue in my particular case was the mongoose-os-libs/i2c library which does not yet support the -C3. I tried adding it, but see there are currently compile issues with the code.

[rojer]

yeah, that message is about lib compatibility. god point about i2c, it needs to be updated

[duncandrennan]

Noting the following also need updates (after trying some of our other code and bumping up against them):

• mongoose-os-libs/adc
• mongoose-os-libs/pwm