Bootloader: Add Reading of Git SHA to bootloader

[joshanne]

Allows the bootloader build to be identified with uploader.py

[joshanne]

This is helpful for users building their own bootloaders, and allowing the user to identify what commit the build was built at.

Feedback welcome.

[joshanne]

I've also got changes that add reading off the Application Git SHA if AP_CHECK_FIRMWARE_ENABLED is enabled in the bootloader (and application).

We certainly would find these handy, just a question of if this is desirable in the bootloader.

[khancyr]

great idea, that would prevent to always have to update the bootloader when you do custom one's !

[tridge]

if we can get away without a protocol change, by checking for a NACK then that would be less risky, otherwise we need to be sure existing bootloader clients are OK

[peterbarker]

Wrote this about 4 years ago - glad someone's pushing through with it (https://github.com/ArduPilot/ardupilot/pull/14768/files)

[joshanne]

If this implementation stands, probably need to include an update to the comments above, here:

ardupilot/Tools/AP_Bootloader/bl_protocol.cpp

Lines 549 to 557 in f0900bd

	// get device info
	//
	// command: GET_DEVICE/<arg:1>/EOC
	// BL_REV reply: <revision:4>/INSYNC/EOC
	// BOARD_ID reply: <board type:4>/INSYNC/EOC
	// BOARD_REV reply: <board rev:4>/INSYNC/EOC
	// FW_SIZE reply: <firmware size:4>/INSYNC/EOC
	// VEC_AREA reply <vectors 7-10:16>/INSYNC/EOC
	// bad arg reply: INSYNC/INVALID

[joshanne]

Wrote this about 4 years ago - glad someone's pushing through with it (https://github.com/ArduPilot/ardupilot/pull/14768/files)

@peterbarker - Your implementation was adding a new command. This implementation makes use of the GET_DEVICE (_INFO) command.

Do you have a feeling either way? I'm less inclined to burn a full command index unnecessarily.

[joshanne]

@peterbarker @tridge - given this is based off PX4-Bootloader, what requirement is there to keep it in sync? would that be a sufficient reason to burn a command index, rather than reading additional device info?

[joshanne]

we should probably bump the size of device flags to uint16 or uint32 given done_get_device_flags is a bitmask, and this PR adds device info fields 7, 8 and 9.

• Pending outcome of this comment: Bootloader: Add Reading of Git SHA to bootloader #28492 (comment)

[tridge]

given this is based off PX4-Bootloader, what requirement is there to keep it in sync?

doesn't need to be completely in sync, but we do need to ensure that flashing ArduPilot when px4 bootloader is used works and vice-versa
some flight controllers that usually run ArduPilot come with the px4 bootloader

[peterbarker]

We should probably PR into the PX4 bootloader the additional "info" IDs so as not to cause collisions down the road. Would require a chunk of documentation of the shape of the relevant data...

[joshanne]

We should probably PR into the PX4 bootloader the additional "info" IDs so as not to cause collisions down the road. Would require a chunk of documentation of the shape of the relevant data...

Documented size and shape of data for Build SHAs - both BL and App SHAs are 64 bits each (16 hex characters each).

Also pushed a PR to PX4 to reserve and maintain compatability with PX4 bootloader.

Only catch at this stage is app_descriptor is a uint32_t sha - so for the time being, we reply with the SHA, with succeeding zeroes, and handle display in uploader.py.

[joshanne]

given this is based off PX4-Bootloader, what requirement is there to keep it in sync?

doesn't need to be completely in sync, but we do need to ensure that flashing ArduPilot when px4 bootloader is used works and vice-versa some flight controllers that usually run ArduPilot come with the px4 bootloader

Tested flashing AP to PX4 and back to AP works as expected. The display of the SHAs and bootloader options only occurs when using --identify.

[peterbarker]

Apparently PX4 might have added an equivalent feature into their bootloader. Might be worth checking how they worked it into the protocol and whether we can be compatible.

[joshanne]

Apparently PX4 might have added an equivalent feature into their bootloader.

Yeah, I had noticed that late yesterday too. grumble grumble.

I'm reducing the scope of this PR to solely implement the bootloader version reporting using the same command as PX4.

Works as is, ArduPilot reports the 16 char sha (eg: 1d1e8e6cbb906865), PX4 reports a custom string (eg: PX4BLv1.16.0g1abc27dd1f).

Should we prefix the sha to look something like the following: APBL.1d1e8e6cbb906865?
If so, is that preferred to be setup at build time (in boards.py)? or run time (in bootloader.cpp)?