Hello hello, We have really shifted the initial focus of the topic because we are concerned about how to solve the problem. As a first step, I would like to know if we agree that we actually have a problem, and once we reach a consensus on that, we can discuss how to address it. Regarding the AI-assisted HAL, we already agree that we cannot simply push a button and accept the automated result immediately. However, with AI assistance, rewriting a driver might not be that complicated if we do it one MCU at a time, building it brick by brick. Ultimately, I would like to know if you are open to trying to internalize the Espressif HAL, or if you prefer to avoid any kind of friction with the vendor.
Em qua., 5 de ago. de 2026 às 13:27, Marco C. <[email protected]> escreveu: > Let me try to explain the methodology so you can open your mind: > > We would make a single PR. The proof of correctness of this PR is that > **each and every one of our esp32 configurations** we have in the tree > right now will be **bit-identical to their out-of-tree hal counterparts**. > There is no need to review any code (but I would still advocate for human > reviews anyway). I mean bit-identical is letting anyone run bdiff and > verify the final .elf of .bin matches byte-by-byte by themselves. > > This is very different from “let's just rewrite it from scratch based on > the documentation”. Every bug and quirk from the current esp hal will be > present to satisfy the needs of even the most conservative developers. > > This is essentially the same as trimming the dead code of esp32-hal, > figuring out the massive work that is matching the idf kconfigs, and > reformatting the code to match the code style and overall organization to > NuttX standards. > > Nobody, except the maintainers will notice any difference. And for the > maintainers, it will make their life easier because now we will have a > pinned in-tree hal that is ours to maintain and keep up to our standards. > > This is much better than the alternative proposals: > > 1. Wait for espressif to merge our contributions there: it will take a long > time since they affect Zephyr and any other OS and will most probably never > happen. > > 2. Fork the esp hal and maintain it ourselves in a separate repo: which > will not match nuttx coding standards and will diverge from the upstream > hal. And we already need to maintain 2+ repos and we all know the nightmare > of keeping them in sync for cross repo contributions and this will make > things exponentially more complicated. > > 2 would require us to watch the esp hal repo and port the fixes to our > repos, and this will still be required it we go the path of bringing it in > tree. > > So I believe a much better answer than “No” is “if it is inexpensive for AI > to do that, let’s try and open a draft PR, and then we evaluate the results > and the outcome. And then we decide”. > > Open your mind. Peace. > > > Marco Casaroli > > On Wed, Aug 5, 2026 at 17:33 Matteo Golin <[email protected]> wrote: > > > The ESP HAL change is a massive undertaking. Having AI relegated to do it > > means that we are going to get an even larger increase of AI generated > PRs, > > and now ones that entirely compose a very critical layer of a highly > > popular vendor device collection on NuttX. Are we going to convince > > Espressif developers to help maintain an AI generated copy of their HAL? > > How are we going to obtain their feedback in the development of a new HAL > > that lives within NuttX? Which developers are going to have an > > understanding of this AI generated HAL? How will it be copyrighted? How > > will we ensure it doesn't violate licensing? > > > > If we move to a NuttX maintained ESP HAL, which is already a large ask, > it > > should be created and maintained by NuttX incrementally to ensure that > it's > > stable, license compatible and has some support from our Espressif > > contributors who have been maintaining our ESP support so far. AI > > generating it in one shot is going to be a huge headache for maintainers. > > It also, in my opinion, pushes us one step closer to being yet another > slop > > project. > > > > Matteo > > > > On Wed, Aug 5, 2026, 11:26 a.m. Marco C. <[email protected]> > wrote: > > > > > Can you please elaborate? > > > > > > > > > Marco Casaroli > > > > > > On Wed, Aug 5, 2026 at 17:23 Matteo Golin <[email protected]> > > wrote: > > > > > > > No. > > > > > > > > On Wed, Aug 5, 2026, 11:21 a.m. Marco C. <[email protected]> > > > wrote: > > > > > > > > > Should we AI-convert all espressif HAL into in-tree nuttx? > > > > > > > > > > It would take a few days, and we can guarantee that the build are > > > > > bit-by-bit matched in day zero, then we would have control of the > > tree > > > > and > > > > > will need to maintain it. > > > > > > > > > > Does not sound too bad. > > > > > > > > > > What do you think? > > > > > > > > > > Marco Casaroli > > > > > > > > > > On Wed, Aug 5, 2026 at 17:16 Tomek CEDRO <[email protected]> wrote: > > > > > > > > > > > NuttX by design and by rule uses its own in-tree hardware > > > > > > implementation for archs, platforms, mcus, boards, drivers, etc, > so > > > it > > > > > > is a self-contained and self-sufficient environment. There are > two > > > > > > exceptions to this rule Espressif and RaspberryPi, unfortunately. > > > > > > > > > > > > We are aware of the issue and its pros and cons. There is not > much > > we > > > > > > can do about ESP because of the design of their tools. Yes it is > a > > > > > > moving target.. whoever worked with standalone esp-idf knows > that. > > > > > > > > > > > > Pros: > > > > > > + There is a dedicated team in Espressif for NuttX development > that > > > > > > maintains the esp-sdk components. > > > > > > + We have always up to date implementations and features. > > > > > > + Easy migration between different ESP chips inside NuttX > > ecosystem. > > > > > > + We have new chips support out-of-the-box for free. > > > > > > > > > > > > Cons: > > > > > > - All ESP implementation in NuttX depends completely on external > > > > > > source that may disappear one day. > > > > > > - If we freeze esp-sdk then we loose updates, features, and > vendor > > > > > > maintenance. > > > > > > - We won't be able to cope with amount of changes in esp-sdk on > our > > > > own. > > > > > > > > > > > > This situation is not perfect from NuttX point of view but > optimal > > > > > > from Espressif point of view, and provides working up-to-date > > > > > > environment for NuttX ESP32* users. We have really good support > > from > > > > > > Espressif, unlike any other vendor. Any big company has its goals > > and > > > > > > rules that we have no choice to follow, and there are other chips > > > that > > > > > > require some binary blobs too. > > > > > > > > > > > > I am not sure if we can do anything about it.. unless you want to > > > > > > start your own fully open-source esp-sdk? It would be perfect to > > have > > > > > > fully open-source radio stacks but its astronomical amount of > work. > > > > > > > > > > > > The simplest solution to a stalled PR is just asking our > community > > to > > > > > > keep pushing until its processed :-) > > > > > > > > > > > > -- > > > > > > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info > > > > > > > > > > > > On Wed, Aug 5, 2026 at 12:21 AM Felipe Moura Oliveira > > > > > > <[email protected]> wrote: > > > > > > > > > > > > > > Hi all, > > > > > > > > > > > > > > I would like to raise a concern about NuttX’s dependency on > > > > Espressif’s > > > > > > > esp-hal-3rdparty < > https://github.com/espressif/esp-hal-3rdparty> > > > > > > repository > > > > > > > and discuss whether there is a way to give the NuttX community > > more > > > > > > control > > > > > > > over the changes required for its development. > > > > > > > > > > > > > > The repository is publicly available, but it is maintained and > > > > > controlled > > > > > > > by a single private company. As a result, external > contributions > > > are > > > > > > > handled according to that company’s internal priorities and > > > > > availability, > > > > > > > which can make it difficult for the NuttX community to address > > > issues > > > > > > that > > > > > > > block our own development. > > > > > > > > > > > > > > As a concrete example, I opened espressif/esp-hal-3rdparty#13 > > > > > > > <https://github.com/espressif/esp-hal-3rdparty/pull/13>, it > has > > > been > > > > > > open > > > > > > > for 28 days. It is a small change consisting of one commit and > 15 > > > > added > > > > > > > lines across two header files—six lines in one file and nine in > > the > > > > > > other. > > > > > > > The PR has been acknowledged, but it has not received a > technical > > > > > review, > > > > > > > and there is no expected completion date. > > > > > > > > > > > > > > I understand that the Espressif maintainers have other > > priorities, > > > > and > > > > > > this > > > > > > > is not intended as criticism of the individuals involved. > > However, > > > I > > > > > > > believe it illustrates a governance problem for NuttX: changes > > > > required > > > > > > to > > > > > > > support NuttX on specific hardware may depend on a repository > > whose > > > > > > review > > > > > > > process and priorities are outside the control of our > community. > > > > > > > > > > > > > > My experience while porting Dropbear < > > > > https://github.com/mkj/dropbear> > > > > > > was > > > > > > > quite different. We encountered some problems during the port, > > but > > > > its > > > > > > > maintainer actively helped by reviewing the code, suggesting > > > changes, > > > > > and > > > > > > > quickly accepting the corresponding upstream pull requests. > > > > > > > > > > > > > > I would therefore like to ask whether it would be possible to > > > > maintain > > > > > a > > > > > > > fork of esp-hal-3rdparty under the Apache/NuttX umbrella, with > > > > > > appropriate > > > > > > > NuttX committers having write access. Such a fork could > continue > > > > > tracking > > > > > > > Espressif’s upstream repository, and generally useful changes > > could > > > > > still > > > > > > > be submitted upstream whenever possible. > > > > > > > > > > > > > > If maintaining a repository under Apache is not feasible or > > > > > > > appropriate, another > > > > > > > suggestion I have is to start building our own HAL and via > > kconfig > > > > > select > > > > > > > between the internal driver or the 3rd-party. If you have other > > > > > > > suggestions, please let's talk about them. > > > > > > > > > > > > > > > > > > > > > > > > > > > > *--Felipe Moura de Oliveira* > > > > > > > Linkedin <https://www.linkedin.com/in/felipe-oliveira-75a651a0 > > > > > > > > > > > > > > > > > > > > > > > -- *Felipe Moura de Oliveira* *Universidade Federal de Minas Gerais* Linkedin <https://www.linkedin.com/in/felipe-oliveira-75a651a0> <https://twitter.com/FelipeMOliveir?lang=pt-br>
