sahil-kale / voyager-bootloader Goto Github PK

It is desired to add a configuration struct that can contain key parameters and feature flags. This will enable the composability of the system and further support the addition of callouts and function modification.

Given the agnostic data link of the bootloader library, it is very possible to integrate SD Card DFU. Thought needs to be given as to how we can optimize the process for a user wanting to implement SD card DFU.

I suspect this will likely involve the user requiring an implementation of the host protocol and then passing the buffer into the bootloader (very similar to how the current unit test system works). Perhaps ACK's are not needed and/or we don't need to compute the CRC after an ACK.

I would expect this to be a primarily documentation effort and seeing if there are any feature flags we can add to optimize the performance of the bootloader with SD cards as it heavily assumes a data link.

The following functions are user implemented:
voyager_bootloader_nvm_write
voyager_bootloader_nvm_read
voyager_bootloader_hal_erase_flash
voyager_bootloader_hal_write_flash
voyager_bootloader_hal_read_flash

If these functions fail, the bootloader should error to the application (and also send to host a general error packet with the voyager error, under the error VOYAGER_DFU_INTERNAL_ERROR) and let the user decide what to do, since they are user implemented functions.

Since we cannot assume the state, the bootloader should 'latch' the error and require init() to be called again

CPPCHECK is easy to install and might be helpful to put in the GitHub workflow

Currently, there is a single function called voyager_bootloader_process_receieved_packet() that may be called asynchronously to let the bootloader know that the next packet can be processed.

NOTE: There may be a bug in this function as voyager_data.pending_data is set to true before the length and message buffer are valid - this should probably be done AFTER they are valid :-)

If I am receiving data from a physical UART (not a CDC UART) then I don't really know when a full "packet" has been received. Yes, I could distinguish a DFU start packet from a data packet, or I could put a character receive timeout on the UART handler, but that requires that my stream handler knows about how Voyager handles data, and we don't want that.

If I call voyager_bootloader_process_receieved_packet() before a full packet is received, the previous contents of message buffer are overwritten instead of appended and things just break.

With an API called voyager_bootloader_check_received_packet() we can have the Voyager bootloader do some rudimentary checking of the message type, length, and tell us if this buffer is ready to process. Return values are:

-1 - buffer has some kind of error (like unknown packet type), you figure out how you want to handle the error
0 - packet is not ready to process yet, but no major errors either
1-n - packet of length (n) is ready to process

When the n bytes are ready to be processed, call voyager_bootloader_process_receieved_packet() as before, and then figure out how to handle any additional characters in your UART buffer ...

Does this make sense?

Perhaps abstract away the init DFU into a function?

Keep references close to the code!

• Basic bootloader theory
• Quickstart Guide
• Detailed overview of bootloader (state machines, all the works)

We currently ask the user to populate application start and end addresses - we can use this to compute if the application size is too big when a start packet is sent. Some code exists for the unit test, but thought needs to go into the state machine

As titled. Should allow for custom seeds or whatever, and adopt the same function signature used.

Blocked by #37 , once that is done this can be added as a function pointer signature

Currently, the voyager bootloader does not explicitly offer support for dual-banked flash systems. However, a user can actually implement dual-banked flash by getting smart with the nvm_read function. A user can add a variable dictating what partition they want to write to that is accessed every time nvm_read is accessed, and based on that variable, returns the correct application size/crc/app start/end addresses.

I don't think this is something the bootloader should support by 'knowing' about the partition as it will deviate from making the bootloader agnostic. Instead, writing a guide and demo on this should be sufficient as the user can effectively control where in flash memory is written and implement dual/triple/n banked systems with this strategy. Might also need a demo