Master #8
Merged
Master #8
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
pyinstaller package for linux is built within the ubuntu-latest image in github workflow. This may cause prbolem with glibc symbol versions on older distributions, where the new symbol versions are not available. Fix this by building on the older ubuntu version. Closes espressif#843 Signed-off-by: Frantisek Hrbata <frantisek.hrbata@espressif.com>
Related to espressif#848 Related to espressif#842
…burn_key_digest Adds --show-sensitive-info flag for two commands: burn_key and burn_key_digest.
This is a no-op change for the upstream toolchain (compiled stubs are binary identical), but is required when building with Debian's riscv64-unknown-elf-gcc compiler.
The flasher_stub Makefile allows for some system-local configuration, either through local.mk, or through environment variables. For example, the compiler prefix can be overridden, by defining e.g. CROSS_ESPRISCV32. However, passing additional flags to the compiler isn't possible right now. Add EXTRA_CFLAGS and EXTRA_CFLAGS_ESPRISCV32 to allow for that option.
Rather than a special "make esp32", create WITHOUT_* variables to selectively disable chip families. Currently, WITHOUT_ESP8266, WITHOUT_ESP32_XTENSA and WITHOUT_ESP32_RISCV32 are defined, but the code can be easily adjusted to allow for all kinds of other sets/combinations.
Since commit 94f29a5 the flasher stub is not embedded in the Python source, but rather included as simple json files. As such, wrap_stub.py --embed was converted to basically just vary the build dir. Rather than keep this indirection and for better clarity, remove that piece of code and replace it by a simple "cp" in the Makefile. While at it, replace the target name from "embed" to "install", as this more akin to a "make install" step.
- fix some assert check in test_espefuse.py - add tests to cover the new functionality
…re burnt For C2 secure boot + flash enc block, we saw that in summary cmd "0's" from secure boot digest part (upper 128 bit) were translated into "?'s" when the block was read protected. For C2, we should apply this translation for lower 128 bits only.
IDF may start using parts of the reserved bytes in the extended header at any time, which will break chip auto-detect in image_info.
Fixes misspelling of `triggered` in serial protocol docs. Signed-off-by: hasheddan <georgedanielmangum@gmail.com>
- https://github.com/tomerfiliba-org/reedsolomon/releases/tag/v1.6.1 - this seems to be related to licenses only. - https://github.com/tomerfiliba-org/reedsolomon/releases/tag/v1.7.0 - this is related to installation. Closes espressif#872
…EY5)
eFuse module has a hardware bug.
It is related to ESP32-C3, C6, S3, H2 chips:
- BLOCK9 (BLOCK_KEY5) can not be used by XTS_AES keys.
For H2 chips, the BLOCK9 (BLOCK_KEY5) can not be used by ECDSA keys.
S2 does not have such a hardware bug.
The image formats know about the special value 0xee used to disable WP. Display this with image_info. E.g.: ESP32-C3 extended image header ============================== WP pin: 0xee (disabled)
Adds support for the W25Q256 and GD25Q256 flash chips. Closes espressif#883
…TAG or USB-OTG Closes espressif#924
The ram-only-header configuration makes only the RAM segments visible to the ROM bootloader placing them at the beginning of the file and altering the segment count from the image header with the quantity of these segments, and also writing only their checksum. This segment placement also may not result as optimal as the standard way regarding the padding gap use among the flash segments that could result in a less fragmented binary. The image built must then handle the basic hardware initialization and the flash mapping for code execution after ROM bootloader boot it. Signed-off-by: Marek Matej <marek.matej@espressif.com> Signed-off-by: Almir Okato <almir.okato@espressif.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
(Please delete any lines which don't apply)
Description of change
This change fixes the following bug(s):
(Please put issue URLs or #number-of-issue here.)
I have tested this change with the following hardware & software combinations:
(Operating system(s), development board name(s), ESP8266 and/or ESP32.)
I have run the esptool.py automated integration tests with this change and the above hardware. The results were:
(Details here: https://docs.espressif.com/projects/esptool/en/latest/contributing.html#automated-integration-tests)