Bootloader v5

[CorvusPrudens]

This PR adds the latest version of the Daisy bootloader. It also updates the core makefile to address the correct USB PID, which has been changed to 0xA360.

[stephenhensley]

I think we can simplify the workflow for users a bit by doing the following, and this is as good a time as any.

Currently a user has to add the following to their project Makefile:

LDSCRIPT = /path/to/linker/in/libDaisy # requires looking in core/
C_DEFS += -DBOOT_APP

and on top of that, they have to know to run a different command (make program-app) to flash it.

I think we could replace that with something like:

# in application Makfile

APP_TYPE = BOOT_SRAM

# in core/Makefile
APP_TYPE ?= NOBOOT # default stays the same as now

# and then handle the modes internally
ifeq ($(APP_TYPE), NOBOOT)

LDSCRIPT ?= $(SYSTEM_FILES_DIR)/STM32H750IB_flash.lds
USBPID = st-pid

else ifeq ($(APP_TYPE), BOOT_SRAM)

C_DEFS += -DBOOT_APP
LDSCRIPT ?= $(SYSTEM_FILES_DIR)/STM32H750IB_qspi.lds
USBPID = daisy-pid

else ifeq ($(APP_TYPE), BOOT_QSPI)

C_DEFS += -DBOOT_APP
LDSCRIPT ?= $(SYSTEM_FILES_DIR)/STM32H750IB_qspi.lds
USBPID = daisy-pid

endif

the make program-dfu recipe can be updated to work for the given configuration, and then changing the application build is as easy as adding a single line.

Custom linkers can still be used in either case, but if someone doesn't know/want to know about that aspect of the usage they don't have to.

I'm open to other names for the APP_TYPE, esp. for NOBOOT, which could be BOOT_NONE, BOOT_FACTORY, BOOT_SYSTEM, etc.

---

The only other aspect that won't be simplified is knowing to put the bootloader on the device first or not, but as long as that's clear in the guide then I think that's fine.

[stephenhensley]

We'll probably want to work a bit more on the guide over time (change app types to a table, screenshots, etc.) but for now I think it's passable.

Everything else seems okay.

[stephenhensley]

Just as some final cleanup I:

• did a bit of formatting in the guide
• updated the linker for the SRAM bootloader to not fill into the reserved SRAM used in the bootloader
• updated to latest version of the bootloader that's being tested

Also I think we could do an update where SRAM can be programmed via openocd as long as we remove the reset by changing:

    $(OCD) -s $(OCD_DIR) $(OCDFLAGS) \
        -c "program ./build/$(TARGET).elf verify reset exit"

to

    $(OCD) -s $(OCD_DIR) $(OCDFLAGS) \
        -c "program ./build/$(TARGET).elf verify exit"

Or something similar, but I haven't tested this yet. So we can try it later.