feat(docs): ufw-firmware flashing#27373
Conversation
💡 Commit messages could be improvedNot blocking, but these commit messages could use some cleanup.
See the commit message convention for details. This comment will be automatically removed once the issues are resolved. |
Phil-Engljaehringer
changed the title
Phil-Engljaehringer
changed the title
github-actions
Bot
added
the
kind:feature
|
|
||
| ### Remote Update | ||
|
|
||
| Firmware can be delivered remotely by bundling `.bin` files into an update archive. An external update tool can extract the archive on the target and copy the CAN firmware files into `/fs/microsd/ufw_staging/`. They are then picked up on the next boot. |
There was a problem hiding this comment.
on the target sounds like it is extracted on the PX4 side, yet this is normally done on the host PC / SOM.
|
|
||
| ### Remote Update | ||
|
|
||
| Firmware can be delivered remotely by bundling `.bin` files into an update archive. An external update tool can extract the archive on the target and copy the CAN firmware files into `/fs/microsd/ufw_staging/`. They are then picked up on the next boot. |
There was a problem hiding this comment.
It is a bit unclear what an update archive should be. Maybe link to upload_skynode.sh as an example of a working implementation.
|
|
||
| Before uploading, the tool can read `/fs/microsd/ufw/FW.db` to check which firmware is already installed and skip files that haven't changed, reducing transfer size. | ||
|
|
||
| `upload_skynode.sh` handles the bundling via the `--ext-fw` flag (repeatable for multiple nodes): |
There was a problem hiding this comment.
nodes is a bit hard to understand here. I would rather say (repeatable for multiple firmware files).
|
No broken links found in changed files. |
| A flat-file database at `/fs/microsd/ufw/FW.db` maps each board ID to the original firmware filename that was installed. | ||
| Stale entries are removed automatically on every boot. |
There was a problem hiding this comment.
I'm trying to work out the workflow.
- Does PX4 use this database to decide if it should install new firmware, or is this intended for the external tool?
- You say "Stale entries are removed automatically on every boot." - when is it stale - every boot? Or if you update the firmware with some new file name, or something else?
There was a problem hiding this comment.
@Phil-Engljaehringer FYI I'm now out for a week. Will look at any responses then.
| 122.bin=122-1.17.63eeff1a.uavcan.bin | ||
| ``` | ||
|
|
||
| ### Remote Update |
There was a problem hiding this comment.
@Phil-Engljaehringer I have subedited the sections above to remove some of the repetition in the intro and add a definition of what we consider a valid binary and APDescriptor (since I didn't know). Please check that.
I wasn't sure how to update this part of the doc because I wasn't clear what you were saying.
I think you're saying that
- you have "some" update tool that might bundle a bin of firmware, and use the firmware database to determine what bin files are actually copied into the staging area
update_skynode.shcan be used as part of this in that it can copy a named firmware to the staging area (I assume that is what--ext-fwdoes?). So you could read the database and then callupdate_skynode.shmultiple times to deploy the desired firmware versions into the staging directory?
3 participants
Solved Problem
The Firmware Update section of the DroneCAN docs did not reflect the firmware upload and flashing pipeline added in this PR: #27043
Solution
Expanded the ## Firmware Update section in index.md to document the staging directory, the boot-time migration flow, the FW.db tracking database, and the remote update workflow via upload_skynode.sh --ext-fw.