Replies: 21 comments 31 replies
-
|
@ajf58 , is your plan to support the DevKitC board once C6 is supported or do you plan to go all for C6? |
Beta Was this translation helpful? Give feedback.
-
|
@rftafas, I'm planning on supporting the DevKitC, and this in turn means adding support for the ESP32-C6. |
Beta Was this translation helpful? Give feedback.
-
|
@ajf58, are you also planing to use hal_espressif? It's not available for C6 yet. |
Beta Was this translation helpful? Give feedback.
-
|
@rftafas I am, yes. AIUI https://github.com/zephyrproject-rtos/hal_espressif is a fork of https://github.com/espressif/esp-idf with some Zephyr Project modifications. Whilst the former doesn't have support for the ESP32-C6, the latter does (in v5.1), so we can update hal_espressif as required. |
Beta Was this translation helpful? Give feedback.
-
|
@ajf58 tks for explaining. As we released documentation for ESP32-C6, I wanted to make sure you wouldn't go down to register level. As for hal_espressif and IDF, we have some ongoing internal work to make it cleaner. If you find shortcomings, let us know. |
Beta Was this translation helpful? Give feedback.
-
Thanks. In the C6's TRM there's a few sections that are in progress, e.g. "Low-power Management (RTC_CNTL)" is currently 11% complete. Do you know if there's a planned update to the TRM? |
Beta Was this translation helpful? Give feedback.
-
|
Unfortunately, I can't state an specific date. It will come, eventually. |
Beta Was this translation helpful? Give feedback.
-
|
Maybe your can try with that if you need ESP-IDF Release v5.1: Obtaining ESP-IDF Release v5.1 (beta) |
Beta Was this translation helpful? Give feedback.
-
|
We are working on S3 and there is a few PRs to be timely submitted. So, unfortunately due to that, no C6 yet. We have started planning for it, though. |
Beta Was this translation helpful? Give feedback.
-
|
FWIW, we started C6. Major hal_espressif improvements to come in order to support it. :) |
Beta Was this translation helpful? Give feedback.
-
|
Could this issue be kept open until support is added/implemented, or is there another issue tracking this? |
Beta Was this translation helpful? Give feedback.
-
|
This became a lower priority activity for me, but I've got a more time to look at this now, and it seems that in ESP-IDF 5.1 there's support for the C6, so I'll take another look. |
Beta Was this translation helpful? Give feedback.
-
|
In that case, I don't suggest using plain ESP-IDF. We are moving away from it and have been using something that extracts only the HAL from IDF repository. Next hal_espressif will look a lot like this repository: https://github.com/espressif/esp-hal-3rdparty/tree/release/v5.1.c . It probably will jump from release to release. We are doing internal tests and when all regressions are fixed, it will replace current hal_espressif. Only then C6 work will start. Finally, a WARNING: end users still are not encouraged to use any form of hal (be it either the hal_espressif or esp-hal-3rdparty) for applications. These repos are intended for system design only, hal is not a public API and it will change without notice. If there is real interest in engaging in pre-alfa, let me know and I'll see what I can do to help. |
Beta Was this translation helpful? Give feedback.
-
|
Hi @ajf58 @rftafas , |
Beta Was this translation helpful? Give feedback.
-
We accept external contribution normally, meaning, feel free to submit any work. I think there is more PRs from Espressif because most people are far more interested to build solutions than supporting platforms, which, TBH, I can't disagree.
While I'm really glad to see this contribution, I'm sad to say that this work is unlikely to be accepted as it is. As I stated above, we are no longer coming from ESP-IDF, but using a filtered repository that takes only the hal components we actually need. Please, if you can, move your work from ESP-IDF to the hal_3rdparty repo above before any PR. This would be the first request we would do when reviewing any PR for 5.1. A lot of GIT gymnastics will wait. That said, let me update a little... Soon, we will be moving the zephyr branch of hal_espressif from ESP-IDF 4.4.x to hal_3rdparty 5.1.c with all the necessary changes. The current zephyr branch will be moved to a new branch named hal_v4.4. Once we do that, any work already based on hal_3rdparty should be simpler to rebase and then a PR more close to accepted. |
Beta Was this translation helpful? Give feedback.
-
|
I will wait a month or two before experimenting with C6 and Zephyr support but if there is anything I could help out with right now, let me know :) |
Beta Was this translation helpful? Give feedback.
-
|
@rftafas , OK, thanks. To check my understanding, currently there's no Zephyr support in https://github.com/espressif/esp-hal-3rdparty.git for existing targets, e.g. all the Zephyr specific files like |
Beta Was this translation helpful? Give feedback.
-
|
Yes, you are looking in the right place and, yes, it is missing a lot of things. That is the 'raw' source of it. On top of that we add a lot more stuff, just like one would have to do if starting from ESP-IDF. As I said, we already did this and should be sharing the results in the next few days. I suggest waiting and then rebasing. If this thread taught us something, it's that we will start with a draft of new hal even if it's not working so people could contribute. We were reluctant to share a partially working draft, but for next hal we will share results early. Before the question, it's probably going to be 5.3 with P4, as HAL 5.2 has P4 as preview and not worth the trouble - as usual, earliest birds need to go for ESP-IDF. |
Beta Was this translation helpful? Give feedback.
-
|
FWIW: https://github.com/zephyrproject-rtos/hal_espressif/tree/hal_v5.1 |
Beta Was this translation helpful? Give feedback.
-
|
Zephyr PR compatible to hal5: #65942 - IT IS A WIP As usual, go ahead with a pioneer mindset, expecting the most defying dangers of the jungle. For product development, stay safe using Zephyr main. |
Beta Was this translation helpful? Give feedback.
-
|
Hi @ajf58, I created a branch basing on both https://github.com/ajf58/zephyr/tree/esp32c6 and #65942 and I started compiling a basic hello-world sample. I corrected some Here is the branch if you are interested: https://github.com/JDuchniewicz/zephyr/tree/esp32_c6_devkitc_1_hal_5_1 I am right now at a stage where I am compiling and getting missing include paths due to missing esp32c6 config files in hal-espressif - I looked at the v5.1 but there is such directory yet. I will try copying esp32c3 hal files and adjusting them accordingly as a workaround for now :) |
Beta Was this translation helpful? Give feedback.
-
|
What I did so far:
Let me know if this is of any use to you @rftafas. |
Beta Was this translation helpful? Give feedback.
-
|
We are not working on C6 right now, although we did 'something', which means chances are that we will accept any work there (as long as it passes review, of course). In time, I'll ask to share any progress, so you can take from it into your work. Although I don't oppose adding C6 right of on hal5, playing it safe is more important to not break current users (C3/32/S2/S3). So, My suggestion is to keep this updated (rebased) and the moment hal5 support 'pack' is merged, create a PR based on this work. Also, last but not least, except of radio parts, H2 and C6 are very similar. You can get 2 for the effort of 1. It is a bargain! :D [edit: typos] |
Beta Was this translation helpful? Give feedback.
-
|
I was informed some people are still tracking this. So, the current draft of HAL5.1/Zephyr is #68760 |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for showing an interest. What I'm up toI've locally picked up this change. I've now got some work from myself and @JDuchniewicz in my Zephyr repo, as well as change to my hal_espressif repo (again, both mine, and also some of @LucasTambor 's work, rebased onto the newest 'upstream' of the HAL). To be and also and rebased some work on top of it (both mine, and work by others such as @JDuchniewicz . I'm working my way around both repos, fixing some issues of my own making (e.g. the linker script I had copied from the C3 needed a bit of work to have even the correct memory sections). I'm also extending support for Espressif RISCV ( How to helpHonestly I'm not sure how to divide the work at this stage. I'm glad the dust has settled on the no-doubt significant task of updating |
Beta Was this translation helpful? Give feedback.
-
|
Hi all, I will be more than glad to work on adding further support for this board as I got up and running on my project with ESP32-WROOM. There were significant changes in the ESP32 stack with the HW Model v2 which I still did not fully grasp. @ajf58 - let's maybe synchronize work somewhere? There are a couple of peripherals that could be added after the initial "Hello World" is done. |
Beta Was this translation helpful? Give feedback.
-
|
Well, we are re-basing what we have internally as well. The first challenge you will face is that since #70505, we no longer use binaries to boot Espressif devices. We also ditched away ESP-IDF partitions. The first thing to do is getting 'simple boot' to work for C6. It is a lot of work. Second, the way we bring things up is that most likely once C6 CPU is up, everything that is working for C3 has a high chance to be already working for C6. It means that what will be lacking to update a feature as 'Supported' in #29394 is "Testing" (hence why we are very welcoming to more testing to be added to our testing rig). So, the main work is:
If one wants to extend the support on Espressif devices while writing code (and not testing or adjusting linkers), I suggest creating drivers for unsupported peripherals (Crypto Accelerators, RMT and etc). I suggest using C3 or S3 to do it and then test on other devices. |
Beta Was this translation helpful? Give feedback.
-
@JDuchniewicz can you add a bit more detail on this? What was "up and running" for you? As mentioned below I think I've got an issue in the linker script and/or problems with cache configuration. I'm keen to hear more about your progress. |
Beta Was this translation helpful? Give feedback.
-
|
@ajf58 Currently traveling - in my project I am using SPI and WiFi drivers so that's what I could test there once the C6 board is booting fine. |
Beta Was this translation helpful? Give feedback.
-
Enabling Simple BootI can build firmware that seems to be valid enough that it can be flashed onto the target and runs. During initialization I get some problems. Here's the current output from I'd like to get my local work into a more useful state for sahring more widely, but I thought for now this might be useful data for others to see. My initial thoughts are that perhaps I've got something misconfigured in the cache logic. |
Beta Was this translation helpful? Give feedback.
-
|
At least correct memory size should be set on config ) spi_flash: Detected size(4096k) larger than the size in the binary image header(2048k |
Beta Was this translation helpful? Give feedback.
-
|
You're right, it looks like I'm under-estimating the amount of flash available. I am hopeful that this is benign, but yes it should be fixed. I'm very interested in why attempting to read the efuses is causing the HP core to panic. |
Beta Was this translation helpful? Give feedback.
-
|
I think the flash size reporting was a bit of a distraction; this issue also shows up using ESP-IDF v5.1.x directly with a Hello World example. Regardless, I've updated my branch so that the relationship of the Dev Kit, ESP32-C6-WROOM-1 module (which is where the 4MB of flash physically is), and the ESP32C6 is more explicit, and this message goes away. |
Beta Was this translation helpful? Give feedback.
-
|
The two branches that need integrating are: Zephyr RTOSmain...ajf58:zephyr:esp32c6_hal_v5_1 Espressif HALzephyrproject-rtos/hal_espressif@zephyr...ajf58:hal_espressif:esp32c6_bringup Is it worth me opening draft PRs at this point to have a way for people to easily comment on specific changes? N.b. the small matter of "it's crashing" needs to be fixed, but perhaps this is worth having a few more people look at. My current goal is to get OpenOCD + GDB working with the zehpyr.elf so I can meaningfully set a hardware breakpoint and step through the code. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for posting your current state. I have gotten your version to run (and crash) on my dev board and I would be glad to help with the effort. After I've located the crash in the RTC initialization (hope we are seeing the same problem), my next plan is also getting a debugger to run and step through. |
Beta Was this translation helpful? Give feedback.
-
I've managed to get OpenOCD and GDB working using the tools provided from ESP IDF v5.1. OpenOCDN.b. the use of PS C:\Espressif\tools\openocd-esp32\v0.12.0-esp32-20230921\openocd-esp32> .\bin\openocd.exe -c "set ESP_RTOS none" -f .\share\openocd\scripts\board\esp32c6-builtin.cfg
Open On-Chip Debugger v0.12.0-esp32-20230921 (2023-09-21-13:40)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
none
Info : only one transport option; autoselecting 'jtag'
Info : esp_usb_jtag: VID set to 0x303a and PID to 0x1001
Info : esp_usb_jtag: capabilities descriptor set to 0x2000
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : esp_usb_jtag: serial (60:55:F9:F6:97:6C)
Info : esp_usb_jtag: Device found. Base speed 24000KHz, div range 1 to 255
Info : clock speed 24000 kHz
Info : JTAG tap: esp32c6.cpu tap/device found: 0x0000dc25 (mfg: 0x612 (Espressif Systems), part: 0x000d, ver: 0x0)
Info : [esp32c6] datacount=2 progbufsize=16
Info : [esp32c6] Examined RISC-V core; found 2 harts
Info : [esp32c6] XLEN=32, misa=0x40903105
Info : starting gdb server for esp32c6 on 3333
Info : Listening on port 3333 for gdb connections
Info : [esp32c6] Hart unexpectedly reset!
Info : [esp32c6] Reset cause (7) - (Main WDT0 core reset)GDBInitial connectionTo help bootstrap using GDB, I've built the "Hello World" example from ESP IDF. This creates a PS C:\Espressif\frameworks\esp-idf-v5.1.3\examples\get-started\hello_world> idf.py gdb
Executing action: gdb
GNU gdb (esp-gdb) 12.1_20231023
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "--host=x86_64-w64-mingw32 --target=riscv32-esp-elf".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".
add symbol table from file "C:\Espressif\frameworks\esp-idf-v5.1.3\examples\get-started\hello_world\build\bootloader\bootloader.elf"
Ignoring packet error, continuing...
warning: unrecognized item "timeout" in "qSupported" response
Ignoring packet error, continuing...
C:/Espressif/frameworks/esp-idf-v5.1.3/examples/get-started/hello_world/build\gdbinit\gdbinit:4: Error in sourced command file:
C:/Espressif/frameworks/esp-idf-v5.1.3/examples/get-started/hello_world/build/gdbinit/connect:3: Error in sourced command file:
Remote replied unexpectedly to 'vMustReplyEmpty': timeout
(gdb) exit
PS C:\Espressif\frameworks\esp-idf-v5.1.3\examples\get-started\hello_world> idf.py gdb
Executing action: gdb
GNU gdb (esp-gdb) 12.1_20231023
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "--host=x86_64-w64-mingw32 --target=riscv32-esp-elf".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".
add symbol table from file "C:\Espressif\frameworks\esp-idf-v5.1.3\examples\get-started\hello_world\build\bootloader\bootloader.elf"
0x400291e8 in ?? ()
add symbol table from file "C:\Espressif\tools\esp-rom-elfs\20230320\esp32c6_rev0_rom.elf"
JTAG tap: esp32c6.cpu tap/device found: 0x0000dc25 (mfg: 0x612 (Espressif Systems), part: 0x000d, ver: 0x0)
[esp32c6] Reset cause (24) - (JTAG CPU reset)
Warning: 'flushregs', an alias for the command 'maintenance flush register-cache', is deprecated.
Use 'maintenance flush register-cache'.
Hardware assisted breakpoint 1 at 0x42006622: file C:/Espressif/frameworks/esp-idf-v5.1.3/examples/get-started/hello_world/main/hello_world_main.c, line 16.
Program received signal SIGINT, Interrupt.
0x4002f474 in __riscv_restore_3 ()Debugging the
|
Beta Was this translation helpful? Give feedback.
-
|
OpenOCD (Espressif version: https://github.com/espressif/openocd-esp32) should work fine using the following commands: (attach openocd): (launch GDB): The file supplied in parameter "-f" is considering USB cable connected directly to the SoC USB pins (see details here: https://docs.espressif.com/projects/esp-idf/en/stable/esp32c6/api-guides/jtag-debugging/tips-and-quirks.html#jtag-debugging-tip-openocd-configure-target) |
Beta Was this translation helpful? Give feedback.
-
|
hi guys, we have a preliminary version of ESP32C6 support with the basic drivers and Simple Boot: #72427 we'll be working on it to have it integrated in the main branch, as more testing and drivers support is needed. Thank you |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for this, @raffarost , this is very exciting and it's great to hear you've got this working. It seems like there's not much value in me trying to debug my errors (although my own personal satisfaction would come from learning what I've got wrong here that's causing my builds to crash). Can the Espressif team share some idea on how they'd like to proceed with this? Would you like external/community involvement at this stage? |
Beta Was this translation helpful? Give feedback.
-
|
First I suggest rebasing. You can also push changes. Then, C6 is not done yet. There is a lot of things still to bring up. More on testing, code polishing, etc. And all peripherals. An alternative idea is going after H2 and use all your learnings. We won't be able to engage it before Q4. A third idea is that we have a sync for hal 5.2 (esp-hal-3rdparty) - while we plan to jump directly to move hal_espressif for 5.3, we won't prevent people doing it for 5.2. Along 5.2 comes P4 preview. On a final note, we do avoid as much as possible to conflict with community work. When people open a request and share a draft PR, we try to help them getting it done (jumping in only if it gets stale). This case was complex due to many big changes, like mandatory hal update and adoption of simpleboot. Also, we had C6 already going internally due to our own schedule, albeit, not on a shareable state. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the reply
I'm assuming you mean push to my own branches, as there's no collaboration repos, correct?
I think this is a rough summary of what support there is in Zephyr for some ESP32 chips, and what has no support Existing ESP32xx support in Zephyr, but not for C6
No support
Personally I'd like to get more peripherals brought up on the C6.
Not a problem from my point of view. For me, this is a medium term side project, allowing me to learn more about Zephyr and RISC-V based SoCs. I'm mainly asking because I'd prefer to work on a chunk that isn't being developed in parallel. Some things I can bringup and test, and more reflect what I'm interested in. Perhaps we can coordinate here? |
Beta Was this translation helpful? Give feedback.
-
|
I suggest that peripherals not supported by any other device to be developed on already supported devices first (C3 preferably) and once it is done for them, try new devices. Internally, this has proven more effective. Any peripheral on the list is a good candidate for engagement. My suggestion is picking one and open a feature request and submit a draft PR asap. This way we know it is being handled and we will only take over if it gets stale. Given the current status, some 'daisy chain' of PR may happen (i.e. "depends"). Also, reviews are always welcome. |
Beta Was this translation helpful? Give feedback.
-
Is this request related to a missing driver support for a particular hardware platform, SoC or board? Please describe.
Describe in details the hardware support being requested and why this support benefits Zephyr.
From Espressif's website at https://www.espressif.com/en/products/socs/esp32-c6
As with other SoCs from Espressif, there are modules built around the SoC, as well as development kits that support the module.
This is a proposal to:
Describe why you are asking for this support?
Describe why you are asking for this support instead of contributing it directly to the tree
I'm raising this issue to give visibility upstream of what I'm working on in my fork at https://github.com/ajf58/zephyr/tree/esp32c6 , so that others may contribute either directly and/or avoid duplication of effort.
If this is a new board or SoC, please state whether you are willing to maintain the Zephyr support for it if it is included in the main tree
Yes.
Additional context
Add any other context or graphics (drag-and-drop an image) about the hardware here.
Press releases and general information can be found on Espressif's website at https://www.espressif.com/en/products/socs/esp32-c6
Beta Was this translation helpful? Give feedback.
All reactions