Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Esp32s2 support #31

Closed
wants to merge 9 commits into from
Closed

Esp32s2 support #31

wants to merge 9 commits into from

Conversation

MabezDev
Copy link
Member

A WIP PR for esp32s2 support.

  • Removes the DATE_REG detection in favour of the CHIP_DETECT magic instead.
  • Adds the esp32s2 module for s2 support.

I can't actually flash anything at the moment, the bootloader returns InvalidMessage:

Command: (10, DATA, 0)
Detected Esp32s2
Command: (13, DATA, 0)
Command: (10, DATA, 0)
Command: (10, DATA, 0)
Command: (9, DATA, 0)
Command: (9, DATA, 0)
Command: (9, DATA, 0)
Command: (9, DATA, 0)
Command: (9, DATA, 0)
Command: (10, DATA, 0)
Command: (10, DATA, 0)
Command: (9, DATA, 0)
Command: (9, DATA, 0)
Command: (13, DATA, 0)
Erase size: 12288
Command: (2, DATA, 0)
Error: bootloader returned an error: InvalidMessage

Any ideas?

Once I figure out whats going on, I think we can probably merge the esp32 & esp32s2 modules by expanding the Chip trait.

Builds on top of #29 & #30

* Remove `cargo_project` it fails to parse complex config.toml
* Instead, retrieve the artifact paths from the cargo build invokation
* Use `anyhow` to handle errors instead of unwraps
* use the chip detect "register" and magic values instead of uart date
reg
* Add esp32s2 bootloader
@jessebraham
Copy link
Member

jessebraham commented Sep 1, 2021

Refer to the following lines in esptool.py:

params = struct.pack('<IIII', erase_size, num_blocks, self.FLASH_WRITE_SIZE, offset)
if isinstance(self, (ESP32S2ROM, ESP32S3BETA2ROM, ESP32S3ROM, ESP32C3ROM, ESP32C6BETAROM, ESP32H2ROM)) and not self.IS_STUB:
     params += struct.pack('<I', 1 if begin_rom_encrypted else 0)

Chips newer than the ESP32 must have an additional field in BeginParams denoting whether or not ROM encryption is being used. The command is being rejected by the bootloader because its length is 4 bytes too short.

Unfortunately, since the chip is defined at runtime we can't #[cfg()] gate this field, so this then causes compatibility issues for the older chips. Some additional restructuring may be required to support both generations of chips.

@icewind1991
Copy link
Member

added the rom encryption parameter in a very hacky way for now, the flashing looks to go fine now.

It now crashes in the bootloader with an "invalid partition table error"

I (24) boot: ESP-IDF v4.4-dev-1404-gc13afea635-dirty 2nd stage bootloader
I (24) boot: compile time 20:23:13
I (25) boot: chip revision: 0
I (29) boot.esp32s2: SPI Speed      : 80MHz
I (33) boot.esp32s2: SPI Mode       : DIO
I (38) boot.esp32s2: SPI Flash Size : 2MB
I (43) boot: Enabling RNG early entropy source...
E (48) flash_parts: partition 0 invalid - offset 0x10000 size 0x3f0000 exceeds flash chip size 0x200000
E (58) boot: Failed to verify partition table
E (63) boot: load partition table error!

@@ -138,6 +138,16 @@ struct BeginParams {
offset: u32,
}

#[derive(Zeroable, Pod, Copy, Clone, Debug)]
#[repr(C)]
struct BeginParamsS2 {
Copy link
Member

@jessebraham jessebraham Sep 2, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This encrypted field applies to all chips except the ESP8266/ESP32 as far as I know. This should probably be the default struct, and we can have a BeginParamsLegacy or something to that effect instead for the older chips.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was thinking of having some way of having per-chip command/parameter structs or otherwise moving some of the flashing logic to the chips.

@icewind1991 icewind1991 mentioned this pull request Sep 3, 2021
2 tasks
@MabezDev MabezDev closed this Sep 16, 2021
@icewind1991 icewind1991 deleted the esp32s2-support branch September 21, 2021 21:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants