Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#983719: esptool: Version 3.0 fixes critical bugs
217 views
Skip to first unread message
Matthias Urlichs
Feb 28, 2021, 3:10:04 PM2/28/21
to
Package: esptool
Version: 2.8+dfsg-1
Severity: serious
Justification: broken
$ esptool erase_flash
esptool.py v2.8
Found 3 serial ports
Serial port /dev/ttyUSB0
Connecting....
Detecting chip type... ESP32
Chip is ESP32D0WDQ6 (revision 1)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: 3c:71:bf:03:2e:0c
Enabling default SPI flash mode...
Erasing flash (this may take a while)...
A fatal error occurred: ESP32 ROM does not support function erase_flash.
... umm ... YES IT DOES.
Version 3.0 works. Please upgrade.
-- System Information:
Debian Release: 10.8
APT prefers stable
APT policy: (700, 'stable'), (600, 'unstable'), (550, 'experimental'), (550, 'oldstable'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.19.0-13-amd64 (SMP w/8 CPU threads)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages esptool depends on:
ii libc6 2.31-9
ii python3 3.9.1-1
ii python3-ecdsa 0.13-3+deb10u1
pn python3-pyaes <none>
ii python3-serial 3.4-4
esptool recommends no packages.
esptool suggests no packages.
Version: 2.8+dfsg-1
Severity: serious
Justification: broken
$ esptool erase_flash
esptool.py v2.8
Found 3 serial ports
Serial port /dev/ttyUSB0
Connecting....
Detecting chip type... ESP32
Chip is ESP32D0WDQ6 (revision 1)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: 3c:71:bf:03:2e:0c
Enabling default SPI flash mode...
Erasing flash (this may take a while)...
A fatal error occurred: ESP32 ROM does not support function erase_flash.
... umm ... YES IT DOES.
Version 3.0 works. Please upgrade.
-- System Information:
Debian Release: 10.8
APT prefers stable
APT policy: (700, 'stable'), (600, 'unstable'), (550, 'experimental'), (550, 'oldstable'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.19.0-13-amd64 (SMP w/8 CPU threads)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages esptool depends on:
ii libc6 2.31-9
ii python3 3.9.1-1
ii python3-ecdsa 0.13-3+deb10u1
pn python3-pyaes <none>
ii python3-serial 3.4-4
esptool recommends no packages.
esptool suggests no packages.
Matthias Urlichs
May 12, 2021, 5:40:03 AM5/12/21
to
it seems that the most important bugfix that 3.0 has, compared to 2.8, is that it's upstream and thus not implicitly sets the --no-stub flag by default. This is bad because some boards require it.
TinyPICO:
$ PYTHONPATH=. python3 ./esptool.py flash_id
esptool.py v3.1-dev
Found 3 serial ports
Serial port /dev/ttyUSB0
Connecting......
Detecting chip type... ESP32
Chip is ESP32-PICO-D4 (revision 1)
Features: WiFi, BT, Dual Core, 240MHz, Embedded Flash, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: d8:a0:1d:54:76:20
Uploading stub...
Running stub...
Stub running...
Manufacturer: c8
Device: 4016
Detected flash size: 4MB
Hard resetting via RTS pin...
$ PYTHONPATH=. python3 ./esptool.py --no-stub flash_id
esptool.py v3.1-dev
Found 3 serial ports
Serial port /dev/ttyUSB0
Connecting....
Detecting chip type... ESP32
Chip is ESP32-PICO-D4 (revision 1)
Features: WiFi, BT, Dual Core, 240MHz, Embedded Flash, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: d8:a0:1d:54:76:20
Enabling default SPI flash mode...
Manufacturer: ff
Device: ffff
Detected flash size: Unknown
Hard resetting via RTS pin...
-- -- Matthias Urlichs
Sebastian Kuzminsky
Feb 2, 2023, 6:10:05 PM2/2/23
to
This is the version in Bullseye (and Bookworm and Sid):
$ esptool version
esptool.py v2.8
2.8
It does not correctly identify e.g. the ESP32-PICO-V3-02, as found on
the Adafruit ESP32 Feather V2, and it can not write the flash:
$ esptool --port /dev/ttyACM2 chip_id
esptool.py v2.8
Serial port /dev/ttyACM2
MAC: e8:9f:6d:20:37:44
$ ~/.local/bin/esptool.py version
esptool.py v4.4
4.4
It works fine with this newer module, and it can write the flash:
$ ~/.local/bin/esptool.py --port /dev/ttyACM2 chip_id
esptool.py v4.4
Serial port /dev/ttyACM2
Connecting....
Detecting chip type... Unsupported detection protocol, switching and trying again...
Features: WiFi, BT, Dual Core, 240MHz, Embedded Flash, Embedded PSRAM, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: e8:9f:6d:20:37:44
MAC: e8:9f:6d:20:37:44
--
Sebastian Kuzminsky
$ esptool version
esptool.py v2.8
2.8
It does not correctly identify e.g. the ESP32-PICO-V3-02, as found on
the Adafruit ESP32 Feather V2, and it can not write the flash:
$ esptool --port /dev/ttyACM2 chip_id
esptool.py v2.8
Serial port /dev/ttyACM2
Connecting....
Detecting chip type... ESP32
Chip is unknown ESP32 (revision 3)
Detecting chip type... ESP32
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: e8:9f:6d:20:37:44
Crystal is 40MHz
Enabling default SPI flash mode...
Warning: ESP32 has no Chip ID. Reading MAC instead.
MAC: e8:9f:6d:20:37:44
Hard resetting via RTS pin...
The latest version (installed with pip) is 4.4:
$ ~/.local/bin/esptool.py version
esptool.py v4.4
4.4
It works fine with this newer module, and it can write the flash:
$ ~/.local/bin/esptool.py --port /dev/ttyACM2 chip_id
esptool.py v4.4
Serial port /dev/ttyACM2
Connecting....
Detecting chip type... Unsupported detection protocol, switching and trying again...
Connecting....
Detecting chip type... ESP32
Chip is ESP32-PICO-V3-02 (revision v3.0)
Detecting chip type... ESP32
Features: WiFi, BT, Dual Core, 240MHz, Embedded Flash, Embedded PSRAM, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: e8:9f:6d:20:37:44
Uploading stub...
Running stub...
Stub running...
Warning: ESP32 has no Chip ID. Reading MAC instead.
Running stub...
Stub running...
MAC: e8:9f:6d:20:37:44
Hard resetting via RTS pin...
An updated package would be appreciated. Thanks!
--
Sebastian Kuzminsky
Faidon Liambotis
Feb 21, 2023, 8:00:04 AM2/21/23
to
Control: retitle -1 Package is severely outdated
Control: severity -1 serious
This package is severely outdated. esptool v2.8, as currently packaged
in Debian, was released in October 2019, almost 3.5 years ago. Upstream
has regularly released newer versions every few months in the meantime,
with the latest being v4.5, released last week.
Newer versions bring a myriad of fixes, as well as equally importantly,
support for newer chips that can be found in the wild.
As I've also reported in #948096, esptool in Debian is crippled right
now by not including any flasher stubs, limiting its usefulness. The
removal was justified at the time, but some of the underlying reasons
have been resolved for a long time now for several of the supported
chips, and only require simple patches to be applied to restore.
(Also note: the packaging and DFSG-ness can be simplified quite a bit,
since the binary blobs are now split into JSON files in the build tree,
that can be cleaned up with Files-Excluded, removing the need for
modifying the source through the uupdate script.)
Given how outdated the source is, and the lack of responses from the
maintainer in the BTS, I do not believe the package is fit for the next
release, therefore I'm elevating the severity to RC.
I should note that while the package seems to meet the criteria for
Salvaging (DevRef 5.12) I don't currently have the bandwidth to maintain
it properly in the long run either. I'm happy to do a one-off NMU to
bring it to a more decent shape, however.
Best,
Faidon
Control: severity -1 serious
This package is severely outdated. esptool v2.8, as currently packaged
in Debian, was released in October 2019, almost 3.5 years ago. Upstream
has regularly released newer versions every few months in the meantime,
with the latest being v4.5, released last week.
Newer versions bring a myriad of fixes, as well as equally importantly,
support for newer chips that can be found in the wild.
As I've also reported in #948096, esptool in Debian is crippled right
now by not including any flasher stubs, limiting its usefulness. The
removal was justified at the time, but some of the underlying reasons
have been resolved for a long time now for several of the supported
chips, and only require simple patches to be applied to restore.
(Also note: the packaging and DFSG-ness can be simplified quite a bit,
since the binary blobs are now split into JSON files in the build tree,
that can be cleaned up with Files-Excluded, removing the need for
modifying the source through the uupdate script.)
Given how outdated the source is, and the lack of responses from the
maintainer in the BTS, I do not believe the package is fit for the next
release, therefore I'm elevating the severity to RC.
I should note that while the package seems to meet the criteria for
Salvaging (DevRef 5.12) I don't currently have the bandwidth to maintain
it properly in the long run either. I'm happy to do a one-off NMU to
bring it to a more decent shape, however.
Best,
Faidon
Faidon Liambotis
Feb 23, 2023, 5:30:05 AM2/23/23
to
On Tue, Feb 21, 2023 at 02:16:40PM +0200, Faidon Liambotis wrote:
> I should note that while the package seems to meet the criteria for
> Salvaging (DevRef 5.12) I don't currently have the bandwidth to maintain
> it properly in the long run either. I'm happy to do a one-off NMU to
> bring it to a more decent shape, however.
Update: I pushed a branch into the main repo, feature/2.8-update, that
> I should note that while the package seems to meet the criteria for
> Salvaging (DevRef 5.12) I don't currently have the bandwidth to maintain
> it properly in the long run either. I'm happy to do a one-off NMU to
> bring it to a more decent shape, however.
just brings up the packaging to modern standards and switches to using
pybuild -- a step necessary given new upstream releases are now using
Python modules etc.
This is still tagged as a 2.8+dfsg-1.1 release that builds the package
as-is with enhancements and no regressions.
I also have changes underway for 4.5, but currently looking into what it
would take dependency-wise to accomplish this, as there are 1-2 new
Python module dependencies that are not present in Debian yet. I'll
follow up once I have something; I expect this to be in the next week or
so.
Regards,
Faidon
Milan Kupcevic
Mar 9, 2023, 7:40:04 AM3/9/23
to
Hi Faidon,
First of all thank you for your work on esptool update. I'm currently
using my available time to work on avrdude for bookworm. If you wish to
co-maintain esptool package feel free to add yourself to uploaders of
this package.
I agree with your assessment. The best course at this point is to upload
the updated package version together with the newly introduced
dependencies to sid and let the system to auto-remove the old package
from bookworm.
As soon as bookworm gets released we can make the updated esptool
available via bookworm-backports.
Milan
First of all thank you for your work on esptool update. I'm currently
using my available time to work on avrdude for bookworm. If you wish to
co-maintain esptool package feel free to add yourself to uploaders of
this package.
I agree with your assessment. The best course at this point is to upload
the updated package version together with the newly introduced
dependencies to sid and let the system to auto-remove the old package
from bookworm.
As soon as bookworm gets released we can make the updated esptool
available via bookworm-backports.
Milan
0 new messages