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