DFU safety and booting wrong image Topic is solved

[Caleb]

I've spent a bit more time on this trying to find a way to give the bootoader some capability of accessing evaluating the upgrade image.

It seems though that the function readFlashDataPage() that is available to the customized bootloader is only able to access the data partition that is established in the factory image.

Also, although it is possible to append any data to a upgrade image, the DFU / flash library code does not permit the DFU procedure to write past the end of the boot partition (into the data partition).
If this were possible then the partition boundary and the length of the upgrade image could be arranged such that a unique identifier would be written into the start of the data partition at the end of the upgrade image.

I hope that Ross or some other XMOS expert will come back to this thread and give some definitive info: is it at all possible for the customized bootloader to read an upgrade image.

I suppose one could do some bit-banging of the I/O pins in the customized bootloader. If the I/Os are accessible to the customize functions then it would be possible to read in the boot partition. Then all you need is a way to put a unique identifier in a known location the upgrade image.

thanks, Caleb

[Caleb]

I suppose one could do some bit-banging of the I/O pins in the customized bootloader. If the I/Os are accessible to the customize functions then it would be possible to read in the boot partition. Then all you need is a way to put a unique identifier in a known location the upgrade image.

And now I just tried this. It seems that when XFLASH is linking the customized loader object with its private bootloader object(s), it won't permit re-use of the I/Os:
xmap: Error: Symbol p_flash_spi_cs is a duplicate port declaration.
xmap: Error: previously declared as spi_ports.spi_ss.

So then I tried to use fl_readImagePage - doesn't seem to link flashlib when making the bootloader...
Is there any access to any other flash access library functions besides reading the data sector?

[Ross]

I suppose one could do some bit-banging of the I/O pins in the customized bootloader. If the I/Os are accessible to the customize functions then it would be possible to read in the boot partition. Then all you need is a way to put a unique identifier in a known location the upgrade image.

And now I just tried this. It seems that when XFLASH is linking the customized loader object with its private bootloader object(s), it won't permit re-use of the I/Os:
xmap: Error: Symbol p_flash_spi_cs is a duplicate port declaration.
xmap: Error: previously declared as spi_ports.spi_ss.

Thats probably reasonable, at this part of the loader you are in the middle of booting, you don't know what state the rest of the boot code has left the flash in.

Most of the problems you are facing are for safety - to stop people accidentally breaking the boot. Using the data-partion seems like the right thing to do - I assume you cannot do that since you have items in the field already?

[Caleb]

Most of the problems you are facing are for safety - to stop people accidentally breaking the boot. Using the data-partion seems like the right thing to do - I assume you cannot do that since you have items in the field already?

Overwriting anything it the data partition is not a problem. However, I need for the DFU image to contain some unique identifying data that can be read by the bootloader.

The fundamental problem: I need for the bootloader be able to read the upgrade image to determine if it is valid for the device. Analyzing what is read is solvable / different challenge.

Can you tell me if it's possible for the bootloader to read from the boot partition?

[richard]

However, I need for the DFU image to contain some unique identifying data that can be read by the bootloader.

How much data do you need to identify the type of image? If the information can be packed in a small number of bits then you might be able to encode it in the version number of the flash image.

[Caleb]

However, I need for the DFU image to contain some unique identifying data that can be read by the bootloader.

How much data do you need to identify the type of image? If the information can be packed in a small number of bits then you might be able to encode it in the version number of the flash image.

Hi Richard, I had the same thought and I've come to the conclusion that this is my only practical option.
I've implemented a simple "customized" loader that will only boot a DFU if it is a specific image number. Though nothing is foolproof, I'd prefer to have the loader read 4 bytes of data in the image.
The goal is simply to prevent a user from loading wrong firmware that intended for another product.
This approach will suffice and likely eliminate wrong DFU image loading.
thanks

[ffomich]

Hi, Caleb.
Do you use Thesycon TUSBAudio DFU to upgrade firmware?

This app has configuration xml file. So you can specify list of supported devices (PID) and corresponding firmware files.
User will only select device from list and press Start. Firmware file will be selected automatically.

So you can prevent incorrect file loading at software level.

See attached file, chapter 7.3.