README.md 6.29 KB
Newer Older
David Mondou's avatar
David Mondou committed
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
# RigTool

A tool for the gateway which changes functionality based on how it is linked. For example:

`ln -sf rigtool boot_counter`

Using a central application like this allows us to reuse code that multiple applications need access to, thus shrinking the total installation size.  It also allows us to make core modifications to the central code without having to duplicate the modifications on multiple code bases.

Rigtool currently has the following functionality:

## boot_counter

Called on boot, this will reset the boot counter and modify the boot partition flags as needed.

boot_counter has the following options:

- `reset` Resets the boot counter if active. If the counter indicates a failed boot, the boot flags will be updated.
- `status` Returns the current counter status as one of the following:
    1. "**FAIL**" The system failed to boot after an update.
    2. "**SUCCESS**" The system succeeded in booting after an update.
    3. "**NORMAL**" The system booted normally.

## boot_toggle

Called after a successful installation, this will toggle the boot flags and set the backup partition flags.  If called without any parameters, it will display the current boot flags.

boot_toggle has the following options:

- `k` or `b`
    Toggle the kernel / boot flag

- `f` or `r`
    Toggle the file system / rootfs flag

Each time a flag is toggled, the previous boot flags are copied to the restore flags position.  Because of this, the flags should only be toggled once, either a single flag, or both together, before a reboot.

If no parameters are supplied, the output will be in the format:

- `Current Flags: <k> <f> <k2> <f2>`

Where:

- `<k>` The currently booted kernel
- `<f>` The currently booted file system
- `<k2>` The kernel to restore to on a failed boot
- `<f2>` The file system to restore to on a failed boot

The flags are represented by a `0` or `1` indicating `main` and `alt` respectively.

## dgua
(Device-Ops Gateway Update Agent)

The Rigado interface to Device Ops over the DDI API.

dgua looks for the configuration file in the following order:
    - /etc/vesta/dgua/dgua.conf
    - /etc/dguc.conf 

The following configurations are stored in dgua.conf:

- Settings to use when downloading updates for end devices:
    - **MAX_INSTANCES** The maximum number of instances allowed
    - **DEVICE_URI** The uri
    - **DEVICE_TENANT** The tenant
- Settings to use when downloading updates for the gateway:
    - **GATEWAY_URI** The uri
    - **GATEWAY_TENANT** The tenant
    - **GATEWAY_TARGET_TOKEN** The target token

dgua has the following options:

- `-u gateway [<uri> [<tenant>]]`
    Update the gateway, outputs the following:
    1. "**Update started**" When the program starts
    2. "**Download started**" When the program starts downloading the update file
    3. "**Installing update**" After the update file has finished downloading
    4. "**Update successful**" After the update was successfully applied
    5. "**Update not successful**" If the update could not be applied
    6. "**Update not needed**" If the update is not needed for the hardware
    7. "**Error: &lt;error message&gt;**" If an error occurred
- `-u <controller id> <security token> [<uri> [<tenant>]]`
    Downloads the files needed to update a controller id. Will return a colon delimited list of files that were downloaded.
- `-q gateway [<uri> [<tenant>]]`
    Query if an update is available for the gateway. Will return:
    1. "**Update available**" If an update is available
    2. "**Update not available**" If an update is not available
- `-q <controller id> <security token> [<uri> [<tenant>]]`
    Query if an update is available for a specific controller id. Will return:
    1. "**Update available**" If an update is available
    2. "**Update not available**" If an update is not available
- `-s <controller id> <token> <execution> <status> <progress> [<uri> [<tenant>]]`
    Send the current status to the server for a specific controller id
    * `<execution>` is one of:
        1. "**canceled**"    The update was canceled
        2. "**rejected**"    The update was rejected
        3. "**closed**"      The update was completed and closed
        4. "**proceeding**"  The update is being worked on
        5. "**scheduled**"   The update is scheduled for a later time
        6. "**resumed**"     Work has resumed on the update
    * `<status>` is one of:
        1. "**success**"     The update was completed successfully
        2. "**failure**"     The update has failed
        3. "**none**"        The update has not finished yet
    * `<progress>` is the percentage done from 0 to 100

## dgua_service

A service that can be run in the background to check the server at set intervals for gateway updates.

dgua_service looks for the configuration file in the following order:
    - /etc/vesta/dgua/dgua.conf
    - /etc/dguc.conf 

The following configurations are stored in dgua.conf:

- **GATEWAY_UPDATE_INTERVAL** The number of minutes between checks for updates. The default value is 60.
- **GATEWAY_URI** The uri
- **GATEWAY_TENANT** The tenant
- **GATEWAY_TARGET_TOKEN** The target token

dgua_service has the following option:

- `-s [<uri> [<tenant>]]` Start the service with the optional uri and tenant. These values will override those in the `dgua.conf` file.

dgua_service will listen for the signals, `SIGINT` (2) and `SIGTERM` (15). If either signal is detected, the service will exit gracefully.

## board_serial_number

Returns the unit serial number that's burned into the gateway's fuses.

## unit_serial_number

Returns the unit serial number that's burned into the gateway's fuses. This is the value used as the controller id when communicating with device ops. If this value is not set, then board_serial_number is used. If that is not set, then hostname is used.

## Other rigtool features:

- For testing, the compiled app can be called with the name of the link as the first parameter. ie:

`a.out boot_counter -h`

- To display help for a function, all functions support the `-h` and `--help` options.

- Internally, code exists to support the flowing functionality:
    1. Reading / Erasing / Writing to nor flash.
    2. Sending and receiving from https servers.
    3. Reading and Writing JSON data.
    4. Printing JSON data to the screen in a human readable form.
    5. Flattening a JSON structure to make it easier to access values.
    6. Read uboot variables