@@ -44,7 +44,7 @@ SWUpdate Documentation
mongoose.rst
suricatta.rst
hawkbit-setup.rst
- swupdate-ipc.rst
+ swupdate-ipc-interface.rst
progress.rst
bindings.rst
building-with-yocto.rst
@@ -62,6 +62,7 @@ Utilities and tools
swupdate-sendtohawkbit.rst
swupdate-progress.rst
swupdate-sysrestart.rst
+ swupdate-ipc.rst
############################################
Help and support
new file mode 100644
@@ -0,0 +1,441 @@
+.. SPDX-FileCopyrightText: 2013-2021 Stefano Babic <sbabic@denx.de>
+.. SPDX-License-Identifier: GPL-2.0-only
+
+===================================
+SWUpdate: API for external programs
+===================================
+
+Overview
+========
+
+SWUpdate contains an integrated web-server to allow remote updating.
+However, which protocols are involved during an update is project
+specific and differs significantly. Some projects can decide
+to use FTP to load an image from an external server, or using
+even a proprietary protocol.
+The integrated web-server uses this interface.
+
+SWUpdate has a simple interface to let external programs
+to communicate with the installer. Clients can start an upgrade
+and stream an image to the installer, querying then for the status
+and the final result. The API is at the moment very simple, but it can
+easy be extended in the future if new use cases will arise.
+
+.. _install_api:
+
+API Description
+===============
+
+The communication runs via UDS (Unix Domain Socket). The socket is created
+at startup by SWUpdate in /tmp/sockinstctrl as per default configuration.
+This socket should, however, not be used directly but instead by the Client
+Library explained below.
+
+The exchanged packets are described in network_ipc.h
+
+::
+
+ typedef struct {
+ int magic;
+ int type;
+ msgdata data;
+ } ipc_message;
+
+
+Where the fields have the meaning:
+
+- magic : a magic number as simple proof of the packet
+- type : one of REQ_INSTALL, ACK, NACK,
+ GET_STATUS, POST_UPDATE, SWUPDATE_SUBPROCESS, SET_AES_KEY
+- msgdata : a buffer used by the client to send the image
+ or by SWUpdate to report back notifications and status.
+
+The client sends a REQ_INSTALL packet and waits for an answer.
+SWUpdate sends back ACK or NACK, if for example an update is already in progress.
+
+After the ACK, the client sends the whole image as a stream. SWUpdate
+expects that all bytes after the ACK are part of the image to be installed.
+SWUpdate recognizes the size of the image from the CPIO header.
+Any error lets SWUpdate to leave the update state, and further packets
+will be ignored until a new REQ_INSTALL will be received.
+
+.. image:: images/API.png
+
+It is recommended to use the client library to communicate with SWUpdate. On the lower
+level with direct socket communication, it cannot be guaranteed that the structures
+will remain compatible in the future. The client library was affected by this issue, too, and it is
+changed to accept an opaque interface that will survive API changes. Compatibility
+layers could be added on-demand in the future due to API changes.
+
+
+Client Library
+==============
+
+Functions to start an update
+----------------------------
+A library simplifies the usage of the IPC making available a way to
+start asynchronously an update.
+
+The library consists of one function and several call-backs.
+
+::
+
+ int swupdate_async_start(writedata wr_func, getstatus status_func,
+ terminated end_func, void *req, ssize_t size)
+ typedef int (*writedata)(char **buf, int *size);
+ typedef int (*getstatus)(ipc_message *msg);
+ typedef int (*terminated)(RECOVERY_STATUS status);
+
+swupdate_async_start creates a new thread and start the communication with SWUpdate,
+triggering for a new update. The wr_func is called to get the image to be installed.
+It is responsibility of the callback to provide the buffer and the size of
+the chunk of data.
+
+The getstatus call-back is called after the stream was downloaded to check
+how upgrade is going on. It can be omitted if only the result is required.
+
+The terminated call-back is called when SWUpdate has finished with the result
+of the upgrade.
+
+Example about using this library is in the examples/client directory.
+
+The `req` structure is casted to void to ensure API compatibility. Am user
+should instantiate it as `struct swupdate_request`. This contains fields that can control
+the update process:
+
+::
+
+ struct swupdate_request {
+ unsigned int apiversion;
+ sourcetype source;
+ int dry_run;
+ size_t len;
+ char info[512];
+ char software_set[256];
+ char running_mode[256];
+ };
+
+A user should first call `swupdate_prepare_req()`
+
+::
+
+ void swupdate_prepare_req(struct swupdate_request *req);
+
+This fills the request structure with default values. After that, the user can fill the
+other fields as:
+
+ - *sourcetype* : one of SOURCE_UNKNOWN, SOURCE_WEBSERVER,
+ SOURCE_SURICATTA, SOURCE_DOWNLOADER, SOURCE_LOCAL
+ - *dry_run* : one of RUN_DEFAULT (set from command line), RUN_DRYRUN, RUN_INSTALL.
+ - *info, len* : a variable length data that can be forwarded to the progress
+ interface. The installer in SWUpdate does not evaluate it.
+ - *software_set* and *running_mode* : this allows one to set the `selection` for the update.
+
+Functions to set AES keys
+-------------------------
+
+The key for decryption can be set with command line parameter (see `-K`), but it is possible
+to set it via IPC. In this way, each update could have a different key.
+
+::
+
+ int swupdate_set_aes(char *key, char *ivt)
+
+The key is for AES-256. The length for key and ivt are then defined by the algorithm amd they are passed as ASCII string, so the length *must* be 64 bytes for key and 32 bytes for IVT.
+
+Functions to control SWUpdate
+-----------------------------
+
+::
+
+ int ipc_send_cmd(ipc_message *msg);
+
+ipc_send_cmd is used to send a command to a SWUpdate subprocess (as suricatta). The function is synchron,
+that means it clocks until the subprocess has answered with ACK or NACK. This function sets `type` to SWUPDATE_SUBPROCESS.
+The caller must then set the other fields in message according to the destination.
+The msgdata field is a structure as:
+
+::
+
+ struct {
+ sourcetype source; /* Who triggered the update */
+ int cmd; /* Optional encoded command */
+ int timeout; /* timeout in seconds if an aswer is expected */
+ unsigned int len; /* Len of data valid in buf */
+ char buf[2048]; /*
+ * Buffer that each source can fill
+ * with additional information
+ */
+ }
+
+The caller fills `source` with the subprocess that acceps the command. Values of cmd
+are in `network_ipc.h`.
+
+Messages for suricatta
+----------------------
+
+suricatta accepts messages in JSON format. The message must be formatted in the `buf` field of
+the message data.
+
+Setting the polling time
+........................
+
+::
+
+ { "polling" : <value in seconds, range 0..X>}
+
+Setting it to 0 has the special meaning that the polling time is retrieved from the Backend
+(if this is supported by the server).
+
+Enable / disable Suricatta daemon
+.................................
+
+::
+
+ { "enable" : true }
+ { "enable" : false }
+
+Set custom device attributes for Suricatta (for Hawkbit implementation)
+.......................................................................
+
+::
+
+ { "identify" : [
+ {
+ "name" : "customizableAttributeOne",
+ "value" : "valueOne"
+ },
+ {
+ "name" : "customizableAttributeTwo",
+ "value" : "valueTwo"
+ }
+ ]}
+
+New attributes can be added at runtime, and existing attributes can be modified in the same
+way. Changes will be reflected on the server in the next poll iteration.
+
+
+Trigger a check on the server
+.............................
+
+This is useful in case the device is mostly offline, and when it is online, it should check
+immediately if an update exists and run it. In fact, after enabling the suricatta daemon,
+the update follows the usual states, and the daemon waits for a polling time before
+loading the new software. This command forces an update (if available) without changing the
+polling time.
+
+::
+
+ { "trigger" : true }
+
+
+Activate an already installed Software
+......................................
+
+After a software was installed, the new software boots and if everything runs fine,
+an acknowledge should be sent to the hawkBit server. If this feature is used, for example
+to let the end user decide if the new software is accepted, the parameters used by the installation
+should be stored during the update process.
+
+::
+
+ { "id" : <action id>,
+ "finished" : "success", "failure", "none",
+ "execution" : ["closed", "proceeding", canceled", "rejected", "resumed"]
+ "details" : [ ]
+ }
+
+Get hawkBit Server Status
+.........................
+
+To provide the hawkBit server status to other processes, it can be requested by
+sending an empty message with message type CMD_GET_STATUS.
+
+The response is a JSON object containing the hawkBit server status <status>.
+<status> is a number representing the value of the channel_op_res_t enum from
+channel_op_res.h. As the hawkBit server is polled, its status can only be
+updated when it has been polled. Therefore the response also contains the
+time <time>, when the hawkBit server has been polled the last time. It is
+provided as ISO 8601 date and time string. (2021-10-14T13:42:37.000+00)
+
+::
+
+ { "server" : {
+ "status" : <status>
+ "time" : <time>
+ }
+ }
+
+An example application can be found under tools/swupdate-gethawkbitstatus.c
+
+API to the integrated Webserver
+===============================
+
+The integrated Webserver provides REST resources to push a SWU package and to get inform about the update process.
+This API is based on HTTP standards. There are to kind of interface:
+
+- Install API to push a SWU and to restart the device after update.
+- A WebSocket interface to send the status of the update process.
+
+Install API
+-----------
+
+::
+
+ POST /upload
+
+This initiates an update: the initiator sends the request and start to stream the SWU in the same
+way as described in :ref:`install_api`.
+
+Restart API
+-----------
+
+::
+
+ POST /restart
+
+If configured (see post update command), this request will restart the device.
+
+
+WebSocket API
+-------------
+
+The integrated Webserver exposes a WebSocket API. The WebSocket protocol specification defines ws (WebSocket) and wss (WebSocket Secure) as two new uniform resource identifier (URI) schemes that are used for unencrypted and encrypted con
+nections, respectively and both of them are supported by SWUpdate.
+A WebSocket provides full-duplex communication but it is used in SWUpdate to send events to an external host after
+each change in the update process. The Webserver sends JSON formatted responses as results of internal events.
+
+The response contains the field type, that defines which event is sent.
+
+.. table:: Event Type
+
+ +-----------+----------------------------------------------------------------+
+ | type | Description of event |
+ +===========+================================================================+
+ | status | Event sent when SWUpdate's internal state changes |
+ +-----------+----------------------------------------------------------------+
+ | source | Event to inform from which interface an update is received |
+ +-----------+----------------------------------------------------------------+
+ | info | Event with custom message to be passed to an external process |
+ +-----------+----------------------------------------------------------------+
+ | message | Event that contains the error message in case of error |
+ +-----------+----------------------------------------------------------------+
+ | step | Event to inform about the running update |
+ +-----------+----------------------------------------------------------------+
+
+
+
+Status Change Event
+-------------------
+
+This event is sent when the internal SWUpdate status change. Following status are supported:
+
+::
+
+ IDLE
+ START
+ RUN
+ SUCCESS
+
+
+Example:
+
+::
+
+ {
+ "type": "status",
+ "status": "SUCCESS"
+ }
+
+Source Event
+------------
+
+This event informs from which interface a SWU is loaded.
+
+::
+
+ {
+ "type": "source",
+ "source": "WEBSERVER"
+ }
+
+The field `source` can have one of the following values:
+
+::
+
+ UNKNOWN
+ WEBSERVER
+ SURICATTA
+ DOWNLOADER
+ LOCAL
+
+Info Event
+------------
+
+This event forwards all internal logs sent with level=INFO.
+
+::
+
+ {
+ "type": "info",
+ "source": < text message >
+ }
+
+Message Event
+-------------
+
+This event contains the error message in case of failure.
+
+
+.. table:: Fields for message event
+
+ +-----------+----------------------------------------------------------------+
+ | name | Description |
+ +===========+================================================================+
+ | status | "message" |
+ +-----------+----------------------------------------------------------------+
+ | level | "3" in case of error, "6" as info |
+ +-----------+----------------------------------------------------------------+
+ | text | Message associated to the event |
+ +-----------+----------------------------------------------------------------+
+
+Example:
+
+::
+
+ {
+ "type": "message",
+ "level": "3",
+ "text" : "[ERROR] : SWUPDATE failed [0] ERROR core/cpio_utils.c : ",
+ }
+
+Step event
+----------
+
+This event contains which is the current step running and which percentage of this step is currently installed.
+
+.. table:: Fields for step event
+
+ +-----------+----------------------------------------------------------------+
+ | name | Description |
+ +===========+================================================================+
+ | number | total number of steps N for this update |
+ +-----------+----------------------------------------------------------------+
+ | step | running step in range [1..N] |
+ +-----------+----------------------------------------------------------------+
+ | name | filename of artefact to be installed |
+ +-----------+----------------------------------------------------------------+
+ | percent | percentage of the running step |
+ +-----------+----------------------------------------------------------------+
+
+Example:
+
+::
+
+ {
+ "type": "step",
+ "number": "7",
+ "step": "2",
+ "name": "rootfs.ext4.gz",
+ "percent": "18"
+ }
@@ -1,441 +1,71 @@
-.. SPDX-FileCopyrightText: 2013-2021 Stefano Babic <sbabic@denx.de>
+.. SPDX-FileCopyrightText: 2021 Stefano Babic <sbabic@denx.de>
.. SPDX-License-Identifier: GPL-2.0-only
-===================================
-SWUpdate: API for external programs
-===================================
+swupdate-ipc
+============
-Overview
-========
+swupdate-ipc sends a specific command to SWUpdate. The following commands are
+enabled:
-SWUpdate contains an integrated web-server to allow remote updating.
-However, which protocols are involved during an update is project
-specific and differs significantly. Some projects can decide
-to use FTP to load an image from an external server, or using
-even a proprietary protocol.
-The integrated web-server uses this interface.
+aes
+---
+send a new aes key to SWUpdate
-SWUpdate has a simple interface to let external programs
-to communicate with the installer. Clients can start an upgrade
-and stream an image to the installer, querying then for the status
-and the final result. The API is at the moment very simple, but it can
-easy be extended in the future if new use cases will arise.
-
-.. _install_api:
-
-API Description
-===============
-
-The communication runs via UDS (Unix Domain Socket). The socket is created
-at startup by SWUpdate in /tmp/sockinstctrl as per default configuration.
-This socket should, however, not be used directly but instead by the Client
-Library explained below.
-
-The exchanged packets are described in network_ipc.h
-
-::
-
- typedef struct {
- int magic;
- int type;
- msgdata data;
- } ipc_message;
-
-
-Where the fields have the meaning:
-
-- magic : a magic number as simple proof of the packet
-- type : one of REQ_INSTALL, ACK, NACK,
- GET_STATUS, POST_UPDATE, SWUPDATE_SUBPROCESS, SET_AES_KEY
-- msgdata : a buffer used by the client to send the image
- or by SWUpdate to report back notifications and status.
-
-The client sends a REQ_INSTALL packet and waits for an answer.
-SWUpdate sends back ACK or NACK, if for example an update is already in progress.
-
-After the ACK, the client sends the whole image as a stream. SWUpdate
-expects that all bytes after the ACK are part of the image to be installed.
-SWUpdate recognizes the size of the image from the CPIO header.
-Any error lets SWUpdate to leave the update state, and further packets
-will be ignored until a new REQ_INSTALL will be received.
-
-.. image:: images/API.png
-
-It is recommended to use the client library to communicate with SWUpdate. On the lower
-level with direct socket communication, it cannot be guaranteed that the structures
-will remain compatible in the future. The client library was affected by this issue, too, and it is
-changed to accept an opaque interface that will survive API changes. Compatibility
-layers could be added on-demand in the future due to API changes.
-
-
-Client Library
-==============
-
-Functions to start an update
-----------------------------
-A library simplifies the usage of the IPC making available a way to
-start asynchronously an update.
-
-The library consists of one function and several call-backs.
-
-::
-
- int swupdate_async_start(writedata wr_func, getstatus status_func,
- terminated end_func, void *req, ssize_t size)
- typedef int (*writedata)(char **buf, int *size);
- typedef int (*getstatus)(ipc_message *msg);
- typedef int (*terminated)(RECOVERY_STATUS status);
-
-swupdate_async_start creates a new thread and start the communication with SWUpdate,
-triggering for a new update. The wr_func is called to get the image to be installed.
-It is responsibility of the callback to provide the buffer and the size of
-the chunk of data.
-
-The getstatus call-back is called after the stream was downloaded to check
-how upgrade is going on. It can be omitted if only the result is required.
-
-The terminated call-back is called when SWUpdate has finished with the result
-of the upgrade.
-
-Example about using this library is in the examples/client directory.
-
-The `req` structure is casted to void to ensure API compatibility. Am user
-should instantiate it as `struct swupdate_request`. This contains fields that can control
-the update process:
-
-::
-
- struct swupdate_request {
- unsigned int apiversion;
- sourcetype source;
- int dry_run;
- size_t len;
- char info[512];
- char software_set[256];
- char running_mode[256];
- };
-
-A user should first call `swupdate_prepare_req()`
-
-::
-
- void swupdate_prepare_req(struct swupdate_request *req);
-
-This fills the request structure with default values. After that, the user can fill the
-other fields as:
-
- - *sourcetype* : one of SOURCE_UNKNOWN, SOURCE_WEBSERVER,
- SOURCE_SURICATTA, SOURCE_DOWNLOADER, SOURCE_LOCAL
- - *dry_run* : one of RUN_DEFAULT (set from command line), RUN_DRYRUN, RUN_INSTALL.
- - *info, len* : a variable length data that can be forwarded to the progress
- interface. The installer in SWUpdate does not evaluate it.
- - *software_set* and *running_mode* : this allows one to set the `selection` for the update.
-
-Functions to set AES keys
--------------------------
-
-The key for decryption can be set with command line parameter (see `-K`), but it is possible
-to set it via IPC. In this way, each update could have a different key.
-
-::
-
- int swupdate_set_aes(char *key, char *ivt)
-
-The key is for AES-256. The length for key and ivt are then defined by the algorithm amd they are passed as ASCII string, so the length *must* be 64 bytes for key and 32 bytes for IVT.
-
-Functions to control SWUpdate
------------------------------
-
-::
-
- int ipc_send_cmd(ipc_message *msg);
-
-ipc_send_cmd is used to send a command to a SWUpdate subprocess (as suricatta). The function is synchron,
-that means it clocks until the subprocess has answered with ACK or NACK. This function sets `type` to SWUPDATE_SUBPROCESS.
-The caller must then set the other fields in message according to the destination.
-The msgdata field is a structure as:
-
-::
-
- struct {
- sourcetype source; /* Who triggered the update */
- int cmd; /* Optional encoded command */
- int timeout; /* timeout in seconds if an aswer is expected */
- unsigned int len; /* Len of data valid in buf */
- char buf[2048]; /*
- * Buffer that each source can fill
- * with additional information
- */
- }
-
-The caller fills `source` with the subprocess that acceps the command. Values of cmd
-are in `network_ipc.h`.
-
-Messages for suricatta
-----------------------
-
-suricatta accepts messages in JSON format. The message must be formatted in the `buf` field of
-the message data.
-
-Setting the polling time
-........................
-
-::
-
- { "polling" : <value in seconds, range 0..X>}
-
-Setting it to 0 has the special meaning that the polling time is retrieved from the Backend
-(if this is supported by the server).
-
-Enable / disable Suricatta daemon
-.................................
-
-::
-
- { "enable" : true }
- { "enable" : false }
-
-Set custom device attributes for Suricatta (for Hawkbit implementation)
-.......................................................................
-
-::
-
- { "identify" : [
- {
- "name" : "customizableAttributeOne",
- "value" : "valueOne"
- },
- {
- "name" : "customizableAttributeTwo",
- "value" : "valueTwo"
- }
- ]}
-
-New attributes can be added at runtime, and existing attributes can be modified in the same
-way. Changes will be reflected on the server in the next poll iteration.
-
-
-Trigger a check on the server
-.............................
-
-This is useful in case the device is mostly offline, and when it is online, it should check
-immediately if an update exists and run it. In fact, after enabling the suricatta daemon,
-the update follows the usual states, and the daemon waits for a polling time before
-loading the new software. This command forces an update (if available) without changing the
-polling time.
-
-::
-
- { "trigger" : true }
-
-
-Activate an already installed Software
-......................................
-
-After a software was installed, the new software boots and if everything runs fine,
-an acknowledge should be sent to the hawkBit server. If this feature is used, for example
-to let the end user decide if the new software is accepted, the parameters used by the installation
-should be stored during the update process.
-
-::
-
- { "id" : <action id>,
- "finished" : "success", "failure", "none",
- "execution" : ["closed", "proceeding", canceled", "rejected", "resumed"]
- "details" : [ ]
- }
-
-Get hawkBit Server Status
-.........................
-
-To provide the hawkBit server status to other processes, it can be requested by
-sending an empty message with message type CMD_GET_STATUS.
-
-The response is a JSON object containing the hawkBit server status <status>.
-<status> is a number representing the value of the channel_op_res_t enum from
-channel_op_res.h. As the hawkBit server is polled, its status can only be
-updated when it has been polled. Therefore the response also contains the
-time <time>, when the hawkBit server has been polled the last time. It is
-provided as ISO 8601 date and time string. (2021-10-14T13:42:37.000+00)
-
-::
-
- { "server" : {
- "status" : <status>
- "time" : <time>
- }
- }
-
-An example application can be found under tools/swupdate-gethawkbitstatus.c
-
-API to the integrated Webserver
-===============================
-
-The integrated Webserver provides REST resources to push a SWU package and to get inform about the update process.
-This API is based on HTTP standards. There are to kind of interface:
-
-- Install API to push a SWU and to restart the device after update.
-- A WebSocket interface to send the status of the update process.
-
-Install API
------------
-
-::
-
- POST /upload
-
-This initiates an update: the initiator sends the request and start to stream the SWU in the same
-way as described in :ref:`install_api`.
-
-Restart API
------------
-
-::
-
- POST /restart
-
-If configured (see post update command), this request will restart the device.
-
-
-WebSocket API
--------------
-
-The integrated Webserver exposes a WebSocket API. The WebSocket protocol specification defines ws (WebSocket) and wss (WebSocket Secure) as two new uniform resource identifier (URI) schemes that are used for unencrypted and encrypted con
-nections, respectively and both of them are supported by SWUpdate.
-A WebSocket provides full-duplex communication but it is used in SWUpdate to send events to an external host after
-each change in the update process. The Webserver sends JSON formatted responses as results of internal events.
-
-The response contains the field type, that defines which event is sent.
-
-.. table:: Event Type
-
- +-----------+----------------------------------------------------------------+
- | type | Description of event |
- +===========+================================================================+
- | status | Event sent when SWUpdate's internal state changes |
- +-----------+----------------------------------------------------------------+
- | source | Event to inform from which interface an update is received |
- +-----------+----------------------------------------------------------------+
- | info | Event with custom message to be passed to an external process |
- +-----------+----------------------------------------------------------------+
- | message | Event that contains the error message in case of error |
- +-----------+----------------------------------------------------------------+
- | step | Event to inform about the running update |
- +-----------+----------------------------------------------------------------+
-
-
-
-Status Change Event
--------------------
-
-This event is sent when the internal SWUpdate status change. Following status are supported:
-
-::
-
- IDLE
- START
- RUN
- SUCCESS
-
-
-Example:
-
-::
-
- {
- "type": "status",
- "status": "SUCCESS"
- }
-
-Source Event
-------------
-
-This event informs from which interface a SWU is loaded.
-
-::
-
- {
- "type": "source",
- "source": "WEBSERVER"
- }
-
-The field `source` can have one of the following values:
-
-::
-
- UNKNOWN
- WEBSERVER
- SURICATTA
- DOWNLOADER
- LOCAL
-
-Info Event
-------------
-
-This event forwards all internal logs sent with level=INFO.
-
-::
+setversion
+----------
+sends a range of versions that can be accepted.
- {
- "type": "info",
- "source": < text message >
- }
+gethawkbit
+----------
+return status of the connection to Hawkbit.
-Message Event
+sendtohawkbit
-------------
+send data to the Hawkbit Server. A typical use case is acknowledgement
+for activation by an application or operator after a new software has been installed.
+The tool can forward the result for the activation to the hawkBit server.
-This event contains the error message in case of failure.
-
-
-.. table:: Fields for message event
+sysrestart
+----------
+send a restart command after a network update
- +-----------+----------------------------------------------------------------+
- | name | Description |
- +===========+================================================================+
- | status | "message" |
- +-----------+----------------------------------------------------------------+
- | level | "3" in case of error, "6" as info |
- +-----------+----------------------------------------------------------------+
- | text | Message associated to the event |
- +-----------+----------------------------------------------------------------+
+SYNOPSIS
+--------
-Example:
+swupdate-ipc <cmd> [option]
-::
+Where cmd is one of the listed above.
- {
- "type": "message",
- "level": "3",
- "text" : "[ERROR] : SWUPDATE failed [0] ERROR core/cpio_utils.c : ",
- }
+DESCRIPTION
+-----------
-Step event
-----------
+aes <key> <ivt>
+ AES key to be used for decryption
-This event contains which is the current step running and which percentage of this step is currently installed.
+setversion <min> <max> <current>
+ configure the accepted range of versions
-.. table:: Fields for step event
+hawkbitcfg
+ configuration for Hawkbit Module
- +-----------+----------------------------------------------------------------+
- | name | Description |
- +===========+================================================================+
- | number | total number of steps N for this update |
- +-----------+----------------------------------------------------------------+
- | step | running step in range [1..N] |
- +-----------+----------------------------------------------------------------+
- | name | filename of artefact to be installed |
- +-----------+----------------------------------------------------------------+
- | percent | percentage of the running step |
- +-----------+----------------------------------------------------------------+
+-h
+ help
+-p
+ allows one to set the polling time (in seconds)
+-e
+ enable suricatta mode
+-d
+ disable suricatta mode
-Example:
+swupdate-sendtohawkbit <action id> <status> <finished> <execution> <detail 1> <detail 2> ..
+ Send Acknolwedge to Hawkbit server after an update if SWUpdate is set to wait for.
-::
+sysrestart
+ Used with SWU handler, allow to perform a network restart
- {
- "type": "step",
- "number": "7",
- "step": "2",
- "name": "rootfs.ext4.gz",
- "percent": "18"
- }
+-r
+ optionally reboot the target after a successful update
+-w
+ waits for a SWUpdate connection instead of exit with error
+-s <path>
+ path to progress IPC socket
Signed-off-by: Stefano Babic <sbabic@denx.de> --- doc/source/index.rst | 3 +- doc/source/swupdate-ipc-interface.rst | 441 ++++++++++++++++++++++++ doc/source/swupdate-ipc.rst | 472 +++----------------------- 3 files changed, 494 insertions(+), 422 deletions(-) create mode 100644 doc/source/swupdate-ipc-interface.rst