[RFC] Remove direct-boot support?

[MabezDev]

With probe-rs now supporting the IDF bootloader format, and that it's impossible to use esp-wifi with direct boot mode I'm wondering if we should remove direct-boot support? Especially since after all this time, we still don't have them quite right, see: #802.

Personally, I'd rather focus our efforts on improving the main linker scripts than trying to maintain both, but if there are some compelling reasons to keep the direct boot linker scripts I'd like to hear them!

[BestClaws]

sad to see this go, as using direct boot gives my c3 like 2x faster flashing time for trivial programs

[MabezDev]

sad to see this go, as using direct boot gives my c3 like 2x faster flashing time for trivial programs

That's a good point! We can definitely improve the repeat flash time speeds for non direct-boot mode. For example, we could get espflash to read the bootloader hash and partition table from the chip and see if they need reflashing if they don't then we just flash the main app (which is essentially what using direct boot mode does). I'll open an issue on the espflash repo.

[AnthonyGrondin]

My 2️⃣ 🪙

I think eventually, direct-boot should be supported as a feature, since it's part of the functionalities this chip offers. I've personally never used it, but it has its advantages, and purpose (Like faster flash times, which can be considerable in repeated flashing operations).

As the HAL is being built, I don't think it's a hard requirement to support it, as there are changes done quite often. I've seen it break quite a few times over the pas year. I believe it could be looked at later, further down the line, once everything has stabilized, and more energy can be fully focused on it.

These SoCs also support secure boot, so that's maybe a thing that could be looked at, at the same time.

[bugadani]

I like having options, but if it turns out that the only argument in favour of direct boot is flashing time, then my take is that the tooling should be improved, and the maintenance burden imposed by direct-boot dropped.

The ideal state of the world would be a single image format that can be either direct booted or loaded by the bootloader, but that's just wishful thinking on my part, it looks like :)

[lucasvr]

Hi folks. Is there a technical reason why Wi-Fi won't work with direct-boot? Does it need special information from the metadata sections that are only declared by mcuboot, or is this a limitation of the current implementation of IDF?

[bjoernQ]

Hi folks. Is there a technical reason why Wi-Fi won't work with direct-boot? Does it need special information from the metadata sections that are only declared by mcuboot, or is this a limitation of the current implementation of IDF?

Not sure if there is really no way to get it working - back then we had a few general problems with direct-boot IIRC and we never really tried it again. Given that we might remove support for direct-boot it's probably a waste of time to look into that again. If we decide to keep direct-boot we should look into it again

[MabezDev]

Based on the effort to maintain them, and the current state of scripts we have decided we will remove the direct boot linker scripts.

Will it ever return?

We're not opposed to it returning, but the maintainability aspect must be addressed for us to consider it.

Is there a way to use it even after the removal?

Yes, instead of linking to -Tlinkall.x (the built-in esp-hal linker scripts), you can maintain your own direct-boot linker scripts. By doing this you are at the mercy of changes in esp-hal needing linker script modifications to be reflected in your own scripts.

PR here: #903