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> > > >
