View source for Reference/bootloader

{| 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==

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.

[[Category:Firmware Flashing]] [[Category:Developer_Documentation]]