Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

firmware.patch handles FAT resources #857

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

jeanparpaillon
Copy link

No description provided.

@jeanparpaillon
Copy link
Author

fwup part implemented in fwup-home/fwup#202

@jeanparpaillon jeanparpaillon force-pushed the 856-handle-fat-resources branch 3 times, most recently from 99a90f4 to 17308b9 Compare March 20, 2023 10:38
With the following patch fwup-home/fwup#202 ,
fwup is able to apply delta updates on FAT resources.

This patch update firmware.patch mix task to create firmware patches
including FAT resources delta updates.
Copy link
Member

@fhunleth fhunleth left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the trick here will be figuring out which files in the archive support deltas and which do not. Unfortunately, this is tricky to figure out since the information is in the meta.conf and it's figured out indirectly. I.e., you have to look at the tasks and see which ones use which resources and whether the source data variables are set. The good news is that if you can do this, if a file isn't used in the task (e.g., the upgrade tasks`), it can be removed completely from the archive.

The other consideration is that zip archive order needs to be preserved for everything in data/ as well.

My other thought is that the patching is complicated enough that I wouldn't mind maintaining it in the fwup repository. I'm not super excited about writing it in C (or shell or python), though. How about let's work on it here and I'll worry about moving it over in the future.

@jeanparpaillon
Copy link
Author

@fhunleth I definitly agree on moving the code to a single place. However, can we split it into:

  • patch creation: elixir code, used by nerves_hub_www, nerves (mix firmware.patch task)
  • patch application: C code, used by fwup

If you agree with this split, I can start an elixir application (nerves_delta ?), that could be used as a dep by nerves and nerves_hub _www for consistency.

I don't really understand why order matters in data as well but I can update the code to tackle with that also.

@jeanparpaillon
Copy link
Author

jeanparpaillon commented Apr 6, 2023

@fhunleth I think part of the complexity lies in matching patch creation with capabilities of fwup. Should we couple this discussion with nerves-hub/nerves_hub_web#556 and imagine the following architecture for OTA:

  • NH pushes meta.conf to device
  • for each resource, device request full data or delta based on its capability, with content-type like negotiation, for instance:
    • GET ...zImage (accept: application/raw)
    • GET ...rootfs (accept: application/raw+xdelta3)

Instead of having NervesHub behaviour depending on device's fwup version, we would just require the device to handle a protocol.

@fhunleth
Copy link
Member

NervesHub already knows the version of fwup running on the device so it can create and send down the proper update. There's no need to create a program or library on the device that does this for NervesHub. A side benefit of this is that firmware updates that don't use the fwup "unsafe" commands can be tested offline (on NervesHub, for example) to verify that they work without needing to send a byte down to a device. I don't know whether we'll get to implementing that right away, but I really like the idea of being able to debug firmware updates without worrying about runtime behavior other than transferring the one firmware update file down (and that's unavoidable).

I added this NervesHub issue to track making different deltas based on the device's fwup version.

I had a brief conversation with @oestrich and @jjcarstens on this. It sounds like there might or might not be concerns on the NervesHub side. I'll try to keep things posted to keep you on the same page.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants