New applications added for IOT2050-SM #511
Conversation
BaochengSu
force-pushed
the
su/iot2050-sm-app-new
branch
from
8ebd309 to
aec5313
Compare
|
Why all theses removal patches in this series? Why not simply starting small and only adding the incomplete things in a later series? |
BaochengSu
force-pushed
the
su/iot2050-sm-app-new
branch
2 times, most recently
from
caf1b74 to
5c51a24
Compare
|
Refined the story line for an easier reviewing. |
BaochengSu
force-pushed
the
su/iot2050-sm-app-new
branch
2 times, most recently
from
d5ea212 to
03a040f
Compare
| install -v -m 644 ${WORKDIR}/iot2050-eiod.service ${D}/lib/systemd/system/ | ||
|
|
||
| install -v -d ${D}/usr/bin/ | ||
| install -v -m 755 ${WORKDIR}/bin/iot2050-eiofsd ${D}/usr/bin/ |
There was a problem hiding this comment.
Ugh, binary-only warning! License remains unclear. But it's also ugly having to carry a 1MB binary with all its future updates in a source repo.
There was a problem hiding this comment.
The eiofsd is an internal Siemens project, and due to some reason, it will not be open sourced.
Indeed this will increase the repo size, just like we already have for SEBoot binaries... But I don't think it's easy to find some place eleswhere to hold them...
There was a problem hiding this comment.
We should clarify licenses - also for the SEBoot binaries as it becomes clear to me only now. Or do we have a statement for the latter already somewhere? Keep in mind that COPYING.MIT, the default license, obviously cannot apply.
There was a problem hiding this comment.
Any idea where to add license clarification of these binaries?
There was a problem hiding this comment.
Next to the binary or in a top-level file (COPYING.BINARY or COPYING.SIEMENS?) that lists the paths along with the license text that applies to those files.
| while True: | ||
| ret = os.write(fd, b'watchdog') | ||
| print("Feeding the watchdog ...") | ||
| time.sleep(30) |
There was a problem hiding this comment.
Watchdog is driven by systemd, at least in the swupdate image. This looks fragile at best.
There was a problem hiding this comment.
Even worse: Our watchdog requires feeding at specific times, not too early. I would refrain from doing this here. The whole example looks questionable TBH.
There was a problem hiding this comment.
Agree.
We should remove this watchdog from the event record service. Instead, this could be put into some wiki or readme.
@huaqianli, any comments?
There was a problem hiding this comment.
Agree. Due to the fact that the watchdog is non-stoppable, getting a watchdog event always requires opening the watchdog and feeding the watchdog.
I removed this example and putted it into a README(WATCHDOG.md) and let the users to decide how to use it.
huaqianli
force-pushed
the
su/iot2050-sm-app-new
branch
2 times, most recently
from
4aa6550 to
b6df9f5
Compare
huaqianli
force-pushed
the
su/iot2050-sm-app-new
branch
4 times, most recently
from
2340a25 to
a620220
Compare
BaochengSu
force-pushed
the
su/iot2050-sm-app-new
branch
2 times, most recently
from
9b3362e to
76ca186
Compare
BaochengSu
force-pushed
the
su/iot2050-sm-app-new
branch
2 times, most recently
from
c3882f5 to
c374ec0
Compare
.github/workflows/main.yml
Outdated
| - name: Build image | ||
| run: ./kas-container build kas-iot2050-swupdate.yml:kas/opt/secure-boot.yml | ||
| run: ./kas-container build kas-iot2050-swupdate.yml:kas/opt/secure-boot.yml:kas/opt/eio.yml |
There was a problem hiding this comment.
I think we don't need to enable EIO in all three cases because it is not directly affected by the variants. Maybe just append it to the secure boot variant?
Actually, but that is an optimization on top, I could imagine folding the RT option into the secure boot target as well to save resources.
There was a problem hiding this comment.
Agree and changed.
Provide service to manage the extended IO (mainly PLC1200 signal modules). Including: - Config the modules, or retrieve the configuration - Sync system time to extended IO controller - Update the firmware of the controller and some modules - currently only controller firmware updating is supported. - Read extended IO events This manager is exposing service to localhost via gRPC, the iot2050-eiod.service is managing this gRPC server. Currently all the gRPC APIs are stub functions, real implementation will be added in later step. Signed-off-by: Baocheng Su <[email protected]>
The extended IO controller is an ASIC, whose job is to configure the signal modules, to collect events from modules, and to provide IO read/write functionalities. All these functionalities are provided through a FUSE filesystem located at /eiofs. The iot2050-eiosd.service is managing this FUSE filesystem. Signed-off-by: Baocheng Su <[email protected]>
For the whole system to have a unified timestamp, esp. for the events, the system time need be synced to the extended IO controller. This is implementated by a service that invoking the gRPC SyncTime API periodically. Signed-off-by: Baocheng Su <[email protected]>
An iot2050-eio cli is provided to config/retrieve the configuration from the console. This cli is purely a gRPC client to call the RPC procedure provided by the iot2050-eiod.service. Currently this is only a stub, implementation will be added later. Signed-off-by: Baocheng Su <[email protected]>
The module configuration is written in YAML, which will be validated via JSON schemas internally. For this YAML file, please check the config-template/sm-config-example.yaml for details. The YAML configuration is internally converted to the binary format which the extended IO controller accepts. Currently only empty slot is avaiable. More modules will be supported later. Signed-off-by: Baocheng Su <[email protected]>
Signed-off-by: Baocheng Su <[email protected]>
Signed-off-by: Baocheng Su <[email protected]>
Signed-off-by: Baocheng Su <[email protected]>
Signed-off-by: Baocheng Su <[email protected]>
The firmware updating is triggerred from the iot2050-eio cli tool. By default it uses the stock version of the firmware file, unless specified by the command line arguments. Signed-off-by: Li Hua Qian <[email protected]> Signed-off-by: Baocheng Su <[email protected]>
This is useful when user upgrades the software of the AM65x part but forgets to upgrade the corresponding extended IO controller firmware. The service periodically reads the current version from eiofs FUSE and compare with the metadata json. If the firmware need upgrade, it will issue: -. A `wall` command calling to notify the logged in users. -. An amber status LED -. A notification when user uses the iot2050-eio cli to deploy/retrieve configs. This is also useful when a same SDCard or USB image is used accorss different IOT devices which have different version of EIO controller FW. Signed-off-by: Li Hua Qian <[email protected]> Signed-off-by: Baocheng Su <[email protected]>
This interface is used for reading the extended IO events from the extended IO controller. Currently EIO controller reports events below: -. Power lost event -. Extended IO controller watchdog event -. Singal Module events Signed-off-by: Li Hua Qian <[email protected]> Signed-off-by: Baocheng Su <[email protected]>
This reminds the user to check the README.md when EIO binaries are not in the bin folder. Signed-off-by: Baocheng Su <[email protected]>
Currently the only supported feature is to config the PLC1200 modules. Web application is easier to use and less error-prone compared to the YAML configuration, but less efficient for mass deployment. This also provides a base when new requirement of web application comes. For the sake of familiarity, react + material UI is used, however in the future, siemens/ix should be used to get a more pretty and unified UI style. This web app should also be possible to pack for the Host PC or server to be a standalone version, the use case is to manipulate the configuration but not deploy/retrieve. Currently this application is only a skeleton, functionalites will be added later. Signed-off-by: Baocheng Su <[email protected]>
Signed-off-by: Baocheng Su <[email protected]>
By calling the gRPC service exposed by the iot2050-eio-manager, the configuration could be deployed to or retrieved from the IOT2050 SM device. Signed-off-by: Baocheng Su <[email protected]>
Signed-off-by: Baocheng Su <[email protected]>
Signed-off-by: Baocheng Su <[email protected]>
Signed-off-by: Baocheng Su <[email protected]>
Signed-off-by: Baocheng Su <[email protected]>
This will save us some space. Also change the SWU image name to make it more clear in the github action download panel. Signed-off-by: Baocheng Su <[email protected]>
Makes EIO subsystem buildable by adding the binary stubs. Note that the build output is not fully functional without the real EIO subsystem binaries. Signed-off-by: Baocheng Su <[email protected]>
Along with the IOT2050 SM variant, some IOT2050 device specific events are recognized as being important for field applications, including: - Device power up - Device power loss - Device case open (uncover) - Device tilting - Device watchdog reset - External module events Although it's possible to collect all these events from variant source, such as syslog, or by customized coding to get the sensor event, it's valuable to provide an unified method or portal to collect all these predefined events from one place. Then this service is added to serve the above purpose, it reads the power up, power loss, eio, tilt, uncover, and (possibly) the watchdog reset events, then writes them into syslog and makes them be readable from gRPC interface. This service could be used directly, or as a base/reference for customization. Signed-off-by: Li Hua Qian <[email protected]>
BaochengSu
force-pushed
the
su/iot2050-sm-app-new
branch
from
e78c39f to
9f93d48
Compare
This is the last part of the IOT2050-SM series, targeting new added applications, including: