You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We have just completed another major overhaul of the epics-containers framework. The primary goal of these changes was to add in support for RTEMS based IOCs. But we have also taken the opportunity to make some other improvements.
12
+
We have just completed another major overhaul of the epics-containers framework. The primary goal of these changes was to add in support for RTEMS based "hard" IOCs. But we have also taken the opportunity to make some other improvements.
13
+
14
+
"Hard" IOC support is currently limited to the VME5500 processor card running RTEMS 5. However this is a proof of principle for an approach that could be extended to any other type of IOC that cannot run inside of a container. In brief:
15
+
16
+
- At container build time the IOC binary is cross compiled.
17
+
- The developer image is kept (in container registry) as an archive of the sources that built the binary
18
+
- The runtime image holds the binary only and is based on a 'proxy' image
19
+
- At runtime, the proxy container places the binaries in a location accessible to the hard IOC
20
+
- The proxy container connects to the 'hard' IOC console and may change config to point the bootloader at the new binaries
21
+
- The proxy container reboots the 'hard' IOC
22
+
- The proxy container attaches the IOC console to its stdout/stdin
23
+
- Now the proxy container can be managed/logged/monitored exactly like a linux IOC
24
+
- We have demonstrated using this approach to locally build and test an RTEMS IOC from a workstation using a vscode developer container.
25
+
13
26
14
27
The tutorials are now up to date with these latest changes, although the RTEMS tutorials are still in development.
0 commit comments