Difference between revisions of "Reference/bootloader"
IHaveADrone (talk | contribs) m (typos) |
|||
| (3 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
{| align=right | |||
|- | |||
|<categorytree style="float:right; clear:right; margin-left:1ex; border: 1px solid gray; padding: 0.7ex;" mode=pages>Firmware Flashing</categorytree> | |||
|} | |||
==Adding a bootloader== | |||
[[Lpc21BootloaderUpload|If you just want to know how to add a bootloader to the LPC]] | |||
==Hardware boot sector== | ==Hardware boot sector== | ||
Each board can be programmed with a serial number and additional board | Each board can be programmed with a serial number and additional board | ||
information (board type, board version, hw options like the type of | information (board type, board version, hw options like the type of GPS | ||
receiver used, manufacturer, mfd date, ...) in a flash sector. This | receiver used, manufacturer, mfd date, ...) in a flash sector. This | ||
hardware sector is written once when the board is programmed for the | hardware sector is written once when the board is programmed for the | ||
| Line 37: | Line 46: | ||
The board serial number can be mentioned in the makefile for the | The board serial number can be mentioned in the makefile for the | ||
aircraft to make sure that it only runs on that board. The board and | aircraft to make sure that it only runs on that board. The board and | ||
board version could be in there. It would be a lot of work and an | |||
additional build system to mention the necessary hardware in each .c | |||
file, maybe not useful. | file, maybe not useful. | ||
| Line 66: | Line 75: | ||
values or similar. We need a safety procedure what to do then. | values or similar. We need a safety procedure what to do then. | ||
[[Category:Developer_Documentation]] | [[Category:Firmware Flashing]] [[Category:Developer_Documentation]] | ||
Latest revision as of 13:02, 14 July 2015
Adding a bootloader
If you just want to know how to add a bootloader to the LPC
Hardware boot sector
Each board can be programmed with a serial number and additional board information (board type, board version, hw options like the type of GPS receiver used, manufacturer, mfd date, ...) in a flash sector. This hardware sector is written once when the board is programmed for the first time and will not be changed (or only if hardware changes are done, e.g. GPS changed). The bootloader and the autopilot software can read the hw sector.
Software boot sector
The software boot sector is rewritten each time a new autopilot software is flashed to the device. It contains the hash value for the build, build date, the aircraft (ID and name) it was built for and other useful configuration information.
It can contain various ways to protect the software from running on an incompatible hardware. The simplest way is to give a hardcoded value for the serial number. The bootloader will at least report a warning if someone tries to flash a software into a hardware that contains the wrong serial number. The sw boot sector could contain a specific hardware type, version and sub information that the software is built for. The bootloader will refuse to flash if this does not fit.
Another way would be to configure the autopilot software "on the fly" if possible. Example: The hw sector contains the type, speed and the serial port (0/1) that the GPS is connected to. The ap software reads this information and configures itself. That way one software elf image could run on almost all hardwares of a type, e.g. Tiny. There are still some hard-to-see limitations, for example if a modem is connected to a serial LPC port that does not have handshake lines but the software requires that. Long and buggy lists would be the result...
Make
The board serial number can be mentioned in the makefile for the aircraft to make sure that it only runs on that board. The board and board version could be in there. It would be a lot of work and an additional build system to mention the necessary hardware in each .c file, maybe not useful.
I think it would be cool to not have any '#ifdef' switches any more. The software can read the configuration and react to that. If there are limitations there could be a a minimum board version (e.g. > V1.1) could be given. If future versions get "too" incompatible, a new board type or board major version is issued.
Sectors
The sectors are "C" structures. All entries are n * 32bit/4bytes long. They start with the ASCII word for "PPRZ" followed by the 32bit value for the maximum overall length. The third value points to the last valid entry in the sector. This value increases each time the structure is enhanced. Entries can be added but must be downwards compatible - it is not allowed to remove values. The last valid word of the sector is a 32bit CRC. The meaning of values is defined through a "C" header or XML file.
On board software
The bootloader should make sure that a valid hw sector exists when flashing new ap software. Nevertheless is could happen that the ap software realizes it could not start due to a crc fail, non valid values or similar. We need a safety procedure what to do then.