1. 14 Jun, 2021 1 commit
  2. 09 Jun, 2021 2 commits
  3. 08 Jun, 2021 3 commits
    • Zygmunt Krynicki's avatar
      spread.yaml: add qemu backend · 49e36e42
      Zygmunt Krynicki authored
      We want to run spread in CI. We cannot use LXD because our executor is
      based on a docker container. We can use qemu though. This should give
      us similar environment to what we already have with LXD, allowing us to
      run all the tests.
      Signed-off-by: Zygmunt Krynicki's avatarZygmunt Krynicki <zygmunt.krynicki@huawei.com>
    • Zygmunt Krynicki's avatar
      spread.yaml: fix undesired mount propagation when testing in VMs · 02dabd7d
      Zygmunt Krynicki authored
      Virtual machines and containers differ with how systemd initializes
      the mount namespace default sharing. Outside of containers systemd
      effectively does mount --make-rshared / early in the boot process.
      This turns on mount event propagation so our mount hacks end up
      clobbering systemctl.real. Use mount --make-unbindable to avoid that.
      Signed-off-by: Zygmunt Krynicki's avatarZygmunt Krynicki <zygmunt.krynicki@huawei.com>
    • Zygmunt Krynicki's avatar
      spread.yaml: reload systemd and dbus after installing sysotad · 8c20b1ad
      Zygmunt Krynicki authored
      Perhaps this is a fluke but while stress-testing project installation
      I've noticed that dbus-daemon doesn't always pick up dev.ostc.sysota1.conf
      file, reporting permission denied error. Perhaps it attempts to open
      the file before install manages to chmod it correctly? In any case
      packaging systems handle that properly. In tests it's sufficient to reload
      As for systemd, this is somewhat unrelated, but if one keeps the test
      environment around, systemd may have a stale idea about what the OTA
      unit files are like, so reloading it helps to get everything pristine.
      Signed-off-by: Zygmunt Krynicki's avatarZygmunt Krynicki <zygmunt.krynicki@huawei.com>
  4. 02 Jun, 2021 2 commits
  5. 01 Jun, 2021 5 commits
  6. 31 May, 2021 6 commits
    • Zygmunt Krynicki's avatar
      boot: implement the boot protocol for the Raspberry Pi bootloader · 8110f385
      Zygmunt Krynicki authored
      The boot protocol we've just defined is now implemented for the "pi
      boot" or the native boot firmware used on the Raspberry Pi.
      The basic idea is that config.txt is configured to point to a concrete
      slot by keeping the kernel, the cmdline.txt and the initrd in a
      sub-directory called "slot-a" or "slot-b" placed on the boot FAT
      Single-boot "try switch" is implemented by writing an appropriate
      modification of "config.txt" as "tryboot.txt" and rebooting the system
      with a special flag parsed by the kernel, resulting in a volatile write
      to a GPU register that is preserved across power-cycle and reset on the
      following reboot. Presence of this flag switches the firmware to read
      the try-mode boot configuration file instead of the standard file.
      Commit is performed by a file rename. As long as that can be done
      atomically we are safe.
      The PiBoot type can has two public fields, the path to the mounted fat
      partition with the firmware configuration files and an optional
      predicate for filtering out conditional sections that do not match the
      current device - mostly useful for model-specific boot configuration.
      Signed-off-by: Zygmunt Krynicki's avatarZygmunt Krynicki <zygmunt.krynicki@huawei.com>
    • Zygmunt Krynicki's avatar
      picfg: implement conditional filter state tracker · 4d12c958
      Zygmunt Krynicki authored
      Conditional filters stack and override each other, depending on their
      type. For example a config.txt file such as:
      Will use a different kernel on a Raspberry Pi 4, with a specific value
      of a GPIO pin (as probed during the boot process) and a specific SoC
      serial number. A config.txt file such as:
      Does not define the kernel property for the Raspberry Pi 3 at all.
      Some filters are more inclusive than others, for example the [pi0]
      filter will match both the raspberry pi 0 and the wireless variant of
      that board (which is also matched by [pi0w] filter).
      Lastly there are two special filters [all], which matches any device and
      [none] which matches no device at all, until some filter comes along to
      change things again.
      This semantic is captured by the StateTracker, which can be used
      alongside the config.txt parser for a stateful analysis of applicable
      configuration parameters.
      Signed-off-by: Zygmunt Krynicki's avatarZygmunt Krynicki <zygmunt.krynicki@huawei.com>
    • Zygmunt Krynicki's avatar
      picfg: model conditional filters as distinct types · 0ed2fbc9
      Zygmunt Krynicki authored
      The config.txt file defines a number of so-called conditional filters
      that constrains when to respect the key=value parameters defined after
      the filter.
      There are several filter types that are documented as recognized by the
      boot loader: [all], [EDID=...], [gpioN={1,1}], [hdmi:{0,1}], [none],
      [0x(serial)] and [(model name)]. They are all documented and implemented
      as distinct text-unmarshallable types.
      Using types from this package allows more precise interpretation of the
      bootloader configuration file, as the one can attempt to deduce which
      sections to recognize and ignore the rest.
      Signed-off-by: Zygmunt Krynicki's avatarZygmunt Krynicki <zygmunt.krynicki@huawei.com>
    • Zygmunt Krynicki's avatar
      picfg: model Raspberry Pi "config.txt" file · f4aabd91
      Zygmunt Krynicki authored
      The configuration file is a slice of sections, sections have an optional
      conditional filter and a slice of properties, each with name and value.
      The package comes with a decoder and encoder, allowing us to understand
      raspberry pi boot configuration files. Conditional filters are modelled
      as simple strings, with a second package available if more precision is
      Signed-off-by: Zygmunt Krynicki's avatarZygmunt Krynicki <zygmunt.krynicki@huawei.com>
    • Zygmunt Krynicki's avatar
      cmd/sysotad: gracefully quit on SIGINT · 9bff6ab4
      Zygmunt Krynicki authored
      While this is done somewhat gracefully already, we may want to handle it
      explicitly to have a chance to save any internal state we want to
      recover at a later time.
      Signed-off-by: Zygmunt Krynicki's avatarZygmunt Krynicki <zygmunt.krynicki@huawei.com>
    • Zygmunt Krynicki's avatar
      boot: define the "boot protocol" interface · fcf4424e
      Zygmunt Krynicki authored
      The boot protocol interface is an ad-hoc definition of an interaction
      protocol between the System OTA service and any boot loader that the
      system is using.
      The protocol is fairly simple: we want to be able to ask the bootloader
      about what is the currently used active and inactive slot - the place
      where we can write a system image. We want to tell the boot loader to
      try to switch to a given slot, along with a perhaps-special reboot
      method that boots that slot only once. Lastly we can commit the switch
      if we are happy with what we found on the following boot.
      There is no "rollback switch" as the system is expected to reboot back
      to the active slot if userspace decides that a rollback is necessary.
      If the initial try boot mode fails, for example by hanging or crashing
      in the kernel, it is expected that the following reboot - automatic or
      manual alike - will boot back to the active slot.
      A slot is merely an A or B moniker without a deeper structure. It is
      expected that as the implementation evolves additional functions will
      allow checking slot properties. This is not explored yet.
      Signed-off-by: Zygmunt Krynicki's avatarZygmunt Krynicki <zygmunt.krynicki@huawei.com>
  7. 28 May, 2021 1 commit
  8. 19 May, 2021 1 commit
  9. 18 May, 2021 1 commit
    • Zygmunt Krynicki's avatar
      Add scaffolding for the D-Bus service · 844a5184
      Zygmunt Krynicki authored
      The service auto-starts on the system bus with the help of systemd and
      bus activation. The service exposes the Maker, Model and update Stream
      properties as well as a pair of methods UpdateStreams and UpdateDevices,
      neither of which is really implemented.
      There's some initial scaffolding for testing using `go test` and
      `spread`, both of which are described by the configuration file.
      There's also initial REUSE compliance, although for the full experience
      one needs unreleased zmk, which makes zmk,  and the files it generates,
      reuse compliant. This is not enforced in CI yet.
      Signed-off-by: Zygmunt Krynicki's avatarZygmunt Krynicki <zygmunt.krynicki@huawei.com>
  10. 17 May, 2021 1 commit
  11. 12 May, 2021 1 commit
  12. 11 May, 2021 1 commit