On Mon, Sep 11, 2017 at 04:51:06PM +0200, Jan Kiszka wrote: > On 2017-09-11 13:35, [ext] Andreas J. Reichel wrote: > > From: Reichel Andreas <[email protected]> > > > > Combine testing and boot_once flag to `ustate`: > > * boot_once = 0, testing = 0: ustate = 0 > > * boot_once = 0, testing = 1: ustate = 1 > > * boot_once = 1, testing = 1: ustate = 2 > > * boot_once = 1, testing = 1, revision = 0: ustate = 3 > > > > The value can be specified as number or as string when > > using the `bg_setenv` utility. Also, an enum is added for > > the API code. > > > > Signed-off-by: Andreas Reichel <[email protected]> > > --- > > docs/TODO.md | 9 -- > > docs/TOOLS.md | 9 +- > > docs/UPDATE.md | 65 +++++----- > > env/fatvars.c | 37 +++--- > > include/envdata.h | 13 +- > > swupdate-adapter/ebgenv.c | 63 +++------- > > swupdate-adapter/swupdate.md | 290 > > ------------------------------------------- > > tools/bg_setenv.c | 78 +++++++----- > > tools/tests/test_api.c | 24 ++-- > > 9 files changed, 138 insertions(+), 450 deletions(-) > > delete mode 100644 swupdate-adapter/swupdate.md > > > > diff --git a/docs/TODO.md b/docs/TODO.md > > index 36c5dfb..e5f4b3e 100644 > > --- a/docs/TODO.md > > +++ b/docs/TODO.md > > @@ -13,15 +13,6 @@ > > method must be defined and implemented to account for generic > > key-value pairs. > > > > -* State refactoring > > - * Currently, there are three variables 'revision', 'testing', > > - 'boot_once', where the latter two are mapped onto a variable called > > - 'ustate'. The 'ustate' variable in turn equals an enum type variable > > - within swupdate, so that for the swupdate adapter, a complex mapping > > - must be implemented. To resolve this issue, the two variables > > - 'boot_once' and 'testing' will be unified to the 'ustate' variable, > > - which will have the same enum type as used in 'swupdate'. > > - > > * API refactoring > > * Currently, there are two APIs, a lower API 'bg_utils.c', and an > > adapter-API 'ebgenv.c'. After refactoring the state variable, the API > > diff --git a/docs/TOOLS.md b/docs/TOOLS.md > > index c79e5a8..9883589 100644 > > --- a/docs/TOOLS.md > > +++ b/docs/TOOLS.md > > @@ -28,7 +28,7 @@ In most cases, the user wants to update to a new > > environment configuration, > > which can be done with: > > > > ``` > > -./bg_setenv --update --kernel="XXXX" --args="YYYY" --watchdog=25 > > --testing=1 > > +./bg_setenv --update --kernel="XXXX" --args="YYYY" --watchdog=25 > > ``` > > > > The `--update` parameter tells `bg_setenv` to automatically overwrite the > > @@ -71,12 +71,15 @@ To simulate a failed update, with its environment data > > stored in config partitio > > issue: > > > > ``` > > -bg_setenv --partition=1 --bootonce --testing=1 --revision=0 > > +bg_setenv --partition=1 --ustate=FAILED --revision=0 > > ``` > > > > +*NOTE*: The user can either specify a number after `--ustate=` or a string > > resembling > > +the value. > > + > > To simulate a reboot of a recently updated configuration stored in config > > partition 1, > > issue: > > > > ``` > > -bg_setenv --partition=1 --boot_once > > +bg_setenv --partition=1 --ustate=TESTING > > ``` > > diff --git a/docs/UPDATE.md b/docs/UPDATE.md > > index 169fb9d..3c84ce4 100644 > > --- a/docs/UPDATE.md > > +++ b/docs/UPDATE.md > > @@ -11,8 +11,8 @@ The structure of the environment data is as follows: > > struct _BG_ENVDATA { > > uint16_t kernelfile[ENV_STRING_LENGTH]; > > uint16_t kernelparams[ENV_STRING_LENGTH]; > > - uint8_t testing; > > - uint8_t boot_once; > > + uint8_t padding; > > + uint8_t ustate; > > uint16_t watchdog_timeout_sec; > > uint32_t revision; > > uint32_t crc32; > > @@ -22,8 +22,10 @@ struct _BG_ENVDATA { > > The fields have the following meaning: > > * `kernelfile`: Path to the kernel image, utf-16 encoded > > * `kernelparams`: Arguments to the kernel, utf-16 encoded > > -* `testing`: A flag that specifies if the configuration is in test mode > > -* `boot_once`: Set by `efibootguard` if it first boots a test configuration > > +* `padding`: Padding byte to stay compatible with the offsets of the > > previous > > + version. > > +* `ustate`: Update status (`0` no action, `1` update installed, `2` > > testing, > > + `3`: update failed) > > Why is 0 called "no action" here and "OK" below? But I agree... if this question arises it's not good. I'll change it.
-- Andreas Reichel Dipl.-Phys. (Univ.) Software Consultant [email protected], +49-174-3180074 TNG Technology Consulting GmbH, Betastr. 13a, 85774 Unterfoehring Geschaeftsfuehrer: Henrik Klagges, Dr. Robert Dahlke, Gerhard Mueller Sitz: Unterfoehring * Amtsgericht Muenchen * HRB 135082 -- You received this message because you are subscribed to the Google Groups "EFI Boot Guard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/efibootguard-dev/20170912085502.GA27820%40iiotirae. For more options, visit https://groups.google.com/d/optout.
