| Message ID | 20240216153024.260416-5-Quirin.Gylstorff@siemens.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | Reduce difference to debian | expand |
On 16.02.24 16:30, Quirin Gylstorff wrote: > From: Quirin Gylstorff <quirin.gylstorff@siemens.com> > > Signed-off-by: Quirin Gylstorff <quirin.gylstorff@siemens.com> > --- > doc/README.swupdate.md | 10 ++++++++++ > 1 file changed, 10 insertions(+) > > diff --git a/doc/README.swupdate.md b/doc/README.swupdate.md > index 1c94699..0f179c4 100644 > --- a/doc/README.swupdate.md > +++ b/doc/README.swupdate.md > @@ -21,6 +21,16 @@ window is still possible. > If the variable `SWU_EBG_UPDATE` is set to `"1"` the update is also stored in > the `*.swu` file. > > +## SWUpdate Hardware compatibility > + > +The variable `SWU_HW_COMPAT` contains a space separate list of > +compatible hardware revisions. > +SWUpdate checks the compatibility against `/etc/hwrevision`, see > +[hardware-compatibility in the SWUpdate documentation.](https://sbabic.github.io/swupdate/sw-description.html#hardware-compatibility) > + > +For testing purpose the content of `/etc/hwrevision` can be set with > +the variable `MACHINE_HW_VERSION`. And what is the pattern to produce that file in production images? Jan > + > # Building and testing the CIP Core image > > Set up `kas-container` as described in the [top-level README](../README.md).
On 2/16/24 16:39, Jan Kiszka wrote: > On 16.02.24 16:30, Quirin Gylstorff wrote: >> From: Quirin Gylstorff <quirin.gylstorff@siemens.com> >> >> Signed-off-by: Quirin Gylstorff <quirin.gylstorff@siemens.com> >> --- >> doc/README.swupdate.md | 10 ++++++++++ >> 1 file changed, 10 insertions(+) >> >> diff --git a/doc/README.swupdate.md b/doc/README.swupdate.md >> index 1c94699..0f179c4 100644 >> --- a/doc/README.swupdate.md >> +++ b/doc/README.swupdate.md >> @@ -21,6 +21,16 @@ window is still possible. >> If the variable `SWU_EBG_UPDATE` is set to `"1"` the update is also stored in >> the `*.swu` file. >> >> +## SWUpdate Hardware compatibility >> + >> +The variable `SWU_HW_COMPAT` contains a space separate list of >> +compatible hardware revisions. >> +SWUpdate checks the compatibility against `/etc/hwrevision`, see >> +[hardware-compatibility in the SWUpdate documentation.](https://sbabic.github.io/swupdate/sw-description.html#hardware-compatibility) >> + >> +For testing purpose the content of `/etc/hwrevision` can be set with >> +the variable `MACHINE_HW_VERSION`. > > And what is the pattern to produce that file in production images? > I would recommend to acquire an HW specific identifier(e.g. dmidecode ) during boot and write it to /etc/hwrevision. I will add some text to the README. Quirin > Jan > >> + >> # Building and testing the CIP Core image >> >> Set up `kas-container` as described in the [top-level README](../README.md). >
diff --git a/doc/README.swupdate.md b/doc/README.swupdate.md index 1c94699..0f179c4 100644 --- a/doc/README.swupdate.md +++ b/doc/README.swupdate.md @@ -21,6 +21,16 @@ window is still possible. If the variable `SWU_EBG_UPDATE` is set to `"1"` the update is also stored in the `*.swu` file. +## SWUpdate Hardware compatibility + +The variable `SWU_HW_COMPAT` contains a space separate list of +compatible hardware revisions. +SWUpdate checks the compatibility against `/etc/hwrevision`, see +[hardware-compatibility in the SWUpdate documentation.](https://sbabic.github.io/swupdate/sw-description.html#hardware-compatibility) + +For testing purpose the content of `/etc/hwrevision` can be set with +the variable `MACHINE_HW_VERSION`. + # Building and testing the CIP Core image Set up `kas-container` as described in the [top-level README](../README.md).