Replies: 2 comments
-
|
If I understood your use case correctly, this might be related to the ideas for custom-client-based streaming discussed in #1440. |
Beta Was this translation helpful? Give feedback.
-
|
This may not match exactly your needs, but take a look at https://github.com/mbessler/imidj/, my casync-insprired content-addressable chunked image download tool that I use with rauc (using a custom hook script). |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
I've been experimenting with understanding the RAUC update system and was wondering on the best approach for having a more traditional update experience that you typically see in printers and routers.... (e.g. uploading form on the device embedded http server).
So far most of my approach has been:
The weakness of this approach is that you would need a large enough location to store the bundle... which seems like a waste considering we are going to copy it over to the slot anyway.
I am aware of HTTP Streaming but that appears to be more of the device acting as a http client requesting chunks off a remote update server. Whereas my scenario is more about sending the update file directly to the device instead.
My question is if there is a way to do 'chunked' updates on the device side? E.g. Instead of writing to an intermediate file... we would send rauc a stream of 256 bytes of the bundle at a time and rauc would write it directly into the slot?
e.g.
rauc write --slot=rootfs --offset=0x1234 --hex=234jh38f23hf28f329234jh38f23hf28f329rauc verify --slot=rootfsThe problems I anticipate would be how to deal with decompression of the squashfs... and decrypting the squashfs... as well as detecting the end of the rauc bundle for the verification of the newly written slot integrity. Which might mean we may need a bundle that is more suitable for sequential streaming directly into a firmware slot file format.
If we do need a file format suitable for streaming to a slot over doing a squashfs mounts, you may want to consider USB Flashing Format (UF2). Which based on reading it's spec appears to allow for writing a very simple parser small enough for a very small bootloader (which might be useful if we could consider a uboot level 'emergency' recovery mode perhaps).
Beta Was this translation helpful? Give feedback.
All reactions