Make a decision on how to handle the direct boot feature of the ESP32-C3 about esp-hal

[jessebraham]

Since the issue of bootloaders is likely rather complex, I'm thinking for the time being we should just default to the standard boot mode supported by all chips and put direct boot behind a feature instead. This keeps the default configuration consistent across devices. We can always change this again in the future if needed, but for right now unless anybody has any objections I think this is probably the correct choice.

[MabezDev]

Controversial take, maybe we should ignore direct boot all together.

Ideally, we'd like to run all our chips without a second stage boot loader, and currently we are basically using the boot loader for two things:

• Setting up the flash mappings and cache
• Reading the partition table and booting the main app

Given that for our no_std use case we only have one "partition", the app partition, that then leaves us with the boot loader only setting up the flash and instruction cache. Maybe we should look at doing that for all our chips?

Maybe this isn't such an easy task, but it seems like MMU is documented in the reference manual (and there are some registers in DPORT to do with the MMU too). At the very least we could cheat for a while and use the ROM functions, until we have a pure Rust solution.

Thoughts?

[bjoernQ]

I probably don't know enough about the first stage boot loader - I thought it can only load code into RAM and executes that?

Long term my concern would be how to handle OTA updates and encryption. Haven't looked into encrypted firmware image handling yet

[ducktec]

Maybe this isn't such an easy task, but it seems like MMU is documented in the reference manual (and there are some registers in DPORT to do with the MMU too). At the very least we could cheat for a while and use the ROM functions, until we have a pure Rust solution.

I remember trying to figure out setting up the cache for the C3 variant and struggling with it:

For the ESP32-C3 there appears to be a dedicated peripheral that is responsible for the cache and the peripheral was not yet documented in the TRM. I just checked again and with ESP32-C3 TRM v0.6 that still seems to be the case: While the dedicated peripheral is mentioned in the peripheral mapping table (address 0x600C_4000), there's no corresponding description. AFAIK, the only way to access the external memory is through the cache, so we also can't just bypass it for the time being.

The official SVD already has the registers and even field descriptions, but their register description reads
<description>This description will be updated in the near future.</description>.

In general (assuming that the peripheral gets eventually documented or with just using the ROM functions), I like the idea to switch to normalboot for the ESP32-C3 by default. That'll probably allow for doing more things in the future (secure boot, flash encryption etc.) and would establish consistency among the variants.

[bjoernQ]

+1 for defaulting to the standard boot for C3, also naming the feature is much easier: "direct-boot" even matches what is used by espflash