MidiBoot for Owl1

Some questions for @mars, I’ve figured it’s better to discuss it here rather than github.

Q1. I’ve noticed that we have firmware flash size set to 320k in linker script. But midiboot allows using an extra sector in its size check.

However, it doesn’t erase that sector, LD script limits us and we don’t have FW size reaching that limit yet. So this is a fairly harmless bug. Apparently this was fixed in develop branch

Q2. Owl1 has bootloader section set to 16k, but FW section starts on 32k. Is that simply because original DFU bootloader fits in 16k? Is that ok to use second sector for bootloader as well? For instance, if someone would have an unhealthy desire to bring midiboot to Owl1.

Btw, that Midiboot port already works (including watchdog stuff), but looks like it refuses to boot flashed firmware - probably something needs to be changed due to FW start address differing from 64k of Owl2 midiboot. But I’ll figure it out soon.

Q3. Why are there errors when loading first patch after firmware update? This seems to be a known issue, but I don’t quite understand what would be causing something like this if firmware and application sections are separated in linker script.

Looks like I’ve got bootloader working, will make a PR tomorrow if I won’t notice any issues. But mass erase, flashing bootloader and loading FW gave me a working module.

Q4. My Owl modular has stm32f405 MCU, but a few places have f407 in configs OpenWare/owl1.mk at master · pingdynasty/OpenWare · GitHub . Are they totally compatible? Should we use one or the other everywhere?

I’ve noticed develop branch has some changes to owl1.ld file. I’ll rebase against it. But it looks like storage section only occupies sectors 7-10, shouldn’t it have its size set to 640k?

nice!
yes it seems you’re right, 640k for storage.
The original bootloader was limited to 16k, with 16k in Sector 1 used for storing settings. But now it should fit in the patch storage space.