Skip to content

GitLab

Gitlab maintenance activity starting at 1700 CET, Friday 15th of October !!!

Switch branch/tag
  1. 13 Oct, 2021 3 commits
  3. 09 Oct, 2021 1 commit
  5. 07 Oct, 2021 3 commits
  7. 30 Sep, 2021 1 commit
  9. 29 Sep, 2021 8 commits
  11. 28 Sep, 2021 3 commits
    • Zygmunt Krynicki's avatar
      Makefile: use SystemdUnit template for systemd units · 345b5118
      Zygmunt Krynicki authored 
      

This ensures that the install location is correct and automatic.
Signed-off-by: Zygmunt Krynicki's avatarZygmunt Krynicki <zygmunt.krynicki@huawei.com>
      345b5118
    • Zygmunt Krynicki's avatar
      .zmk-modules: add template for installing systemd units · a579b52e
      Zygmunt Krynicki authored 
      

Systemd units are a thin wrapper to the InstallUninstall template. Units
can be either system-wide (default) or user-session (by setting
$(unit).IsUser to non-empty value). The InstallDir is set to the
appropriate location for the unit type and is obtained by querying
pkg-config systemd module.
Signed-off-by: Zygmunt Krynicki's avatarZygmunt Krynicki <zygmunt.krynicki@huawei.com>
      a579b52e
    • Zygmunt Krynicki's avatar
      .zmk-modules: add template for using pkg-config · 2731bf9a
      Zygmunt Krynicki authored 
      

The new PkgConfig template uses PkgConfig.Cmd, by default the
pkg-config executable found on PATH, to check availability of
pkg-config modules.

Each module must have the $(module).AtLeastVersion variable defined, the version
check is checked at compile time but is not enforced. The outcome of the
check is stored in PkgConfig.Modules.$(module).Status and is one of
"sufficient", "outdated" or "missing".

Each module that is not missing will have a number of standard variables
populated under the PkgConfig.Modules.$(module) namespace, those are
.Version, .Cflags, .CflagsOnlyI, .CflagsOnlyOther, .Libs,
.LibsOnlyLowerL, .LibsOnlyL and .LibsOnlyOther.

In addition a module may also have any number of module variable names
listed in $(module).Variables. Those are resolved using pkg-config
--variable= and are available under the namespace
PkgConfig.Modules.$(module).Variables.$(variable).
Signed-off-by: Zygmunt Krynicki's avatarZygmunt Krynicki <zygmunt.krynicki@huawei.com>
      2731bf9a
  13. 24 Sep, 2021 1 commit
    • Zygmunt Krynicki's avatar
      boot/piboot: use $(system)/usr/lib/sysota/boot-assets · a4f73996
      Zygmunt Krynicki authored 
      The effective change is from $(system)/boot to
$(system)/usr/lib/sysota/boot-assets. A small slice of code and tests
are affected.

After discussing the boot asset location with Andrei we've decided to
switch away from $(system)/boot - namely the boot directory in the
system partition to the aforementioned new location under
SystemOTA-specific directory.

The rationale for that is comprised of several observations:

1) The /boot directory is not synonymous to the $(boot) partition.

The contents of the boot partition are what SystemOTA needs but the
content of the /boot directory is platform specific and, in fact, there
are already platforms where those are not identical. By choosing a new,
explicit location, that is specific to SystemOTA update process, we
avoid this problem entirely.

2) SystemOTA uses a custom slot-{a,b}/ directory structure in $(boot).

The exact details of how SystemOTA manages the boot partition may change
over time but in any case, are a custom extension that is not widely
recognized.

We had an existing design problem that $(boot), as it came out of the
build system, was not really representative of the $(boot) partition
after several (or even the first) updates. Most clearly, the slot
structure is not represented there at all.

There are several ways we could have addressed that: by teaching the
build system about SystemOTA specific (and perhaps platform specific)
layout, by creating a tool which encapsulates that knowledge and build
out of SystemOTA tree or by ignoring it.

We had the same problem with boot assets inside the image, should it
have the slot structure? Should it be identical to the boot assets on a
vanilla system on first boot?

The solution we chose is to avoid the problem entirely and avoid the
need for special tooling. This is how it works.

The build system produces regular boot partition without any special
sauce. The build system has a small SystemOTA specific logic, to copy
everything present in the $(boot) partition to the $(system) partition,
as explained above. This is also implemented in meta-ohos by [1].

Most importantly this has the following property: there is no more need
to pre-process the image or have a special, and perhaps fragile, first
boot which re-organizes the critical boot partition.

Instead, on the first update, the boot protocol can remove up assets
that underwent slotted duplication (like the kernel) and leave
everything else (like firmware files) intact. In other words, on the
first update, after it succeeds and we start to clean up, we can remove
files that we are certain not to be needed anymore. This is also an
entirely *optional* step. It can be skipped or aborted mid-way without
any consequences.

3) Using a generic location like /usr/lib/boot-assets is risky

While it is tempting to offer standardization, we believe this step is
premature. Using a directory specific to the OTA project allows us to
experiment and make mistakes at a smaller scope.

[1] https://git.ostc-eu.org/OSTC/OHOS/meta-ohos/-/merge_requests/268

Signed-off-by: Zygmunt Krynicki's avatarZygmunt Krynicki <zygmunt.krynicki@huawei.com>
      a4f73996
  15. 16 Sep, 2021 13 commits
  17. 15 Sep, 2021 1 commit
  19. 14 Sep, 2021 1 commit
  21. 13 Sep, 2021 5 commits

Privacy policy Cookies policy