Hi,

I had to add stub_flasher_32.json file manually from upstream repo in
order to make my esphome (not yet in Debian, working on it) work with
ESP32 WROOM 32 board.

Please include this file in the package. TIA

Control: block -1 by 868895
isn't "just" a JSON data file that has been accidentally omitted from
the package. It's in fact a (JSON-wrapped) binary, compiled from C
sources bundled with the esptool source (and built with gcc, and a libc
and everything). So it's not a matter of including the file, but rather
rebuilding it.

A lot of work has happened in Debian and with upstream over the years to
build these binaries from unmodified sources, which culminated with
Debian shipping the stubs for the ESP8266, as well as for the ESP32
RISC-V variants (ESP32-C2, ESP32-C3, ESP32-C6, ESP32-H2). See the
4.5.1+dfsg-0.1 and 4.6.2+dfsg-0.1 changelog entries, Debian bug #948096,
as well as upstream issues #458, #499 and PRs #500, #501, #856, #858.

The reason that the same has not happened yet for the ESP32, ESP32-S2
and ESP32-S3 stubs is that we lack the toolchain for them in Debian
(gcc, binutils & picolibc). picolibc seems to have gained ESP32 support
upstream in 1.7.9, and Keith Packard is both upstream and the Debian
maintainer for it, so I suppose it won't be too hard to persuade him.
gcc and binutils are more complicated. #868895 provides some context,
and Jonathan McDowell, who maintains gcc-xtensa-lx106 and
binutils-xtensa-lx106, is aware of the need. I think there is more of a
backstory there, but he has the details.

Note that the ESP-IDF is thankfully *not* needed anymore (see upstream
#458).

As an alternative, we could probably ship these three stubs as built by
upstream separately in non-free, but I wasn't motivated enough, and I
was hoping we'd get the toolchain in Debian at some point. (I'm not even
the maintainer for esptool. If you're interested, I'm sure Milan will
appreciate the help!).

Finally, note that the stub isn't always necessary. --no-stub should
work for some, but not all, operations, sometimes at slower speeds.

Hope this helps!

Faidon

When I originally ITPed the lx106/ESP8266 variants I got some strong
pushback about how we should really have a unified gcc/binutils that
would be able to cope with various Xtensa variants. That doesn't seem to
have happened. Faidon has done some work on building multiple versions
from a single source, and I've finally accepted this is a better
situation for now than not having the support at all.

As a first step I've renamed the source binutils-xtensa-lx106 package to
binutils-xtensa. I've got some changes pulled in from Faidon's work that
will then build an ESP32 binutils package (I don't have later devices to
test with) that I'll look at uploading once the new source package
clears NEW.

GCC is a bit more complex; when I tried previously I had problems with
ESP-IDF, and I don't think a version that doesn't allow building with
the upstream SDK is useful. I'll have a further poke at that to see if I
can figure out what was going wrong.

J.