Git Product home page Git Product logo

meta-mender-community's Introduction

Yocto community integration layers for Mender

Mender is an open source over-the-air (OTA) software updater for embedded Linux devices. Mender comprises a client running at the embedded device, as well as a server that manages deployments across many devices.

This repository contains Yocto integration layers for various boards.

Please check out https://hub.mender.io for more information on supported boards and instructions on how to setup environment and build images.

Mender logo

Structure

This section is for anyone interested in contributing support for a board.

meta-mender-community is a repository containing multiple Yocto layers for integrating Mender onto various boards.

The layers are structured based on upstream BSP layers and not individual boards.

There are multiple types of layers included here.

SoC-oriented:

  • meta-mender-amlogic
  • meta-mender-nxp
  • meta-mender-tegra ...

Vendor-oriented:

  • meta-mender-raspberrypi
  • meta-mender-toradex-nxp
  • meta-mender-octavo-osd32mp ...

Naming of integration layers follows the upstream naming conventions with SoM vendor layer name having priority. The convention is:

   meta-mender-<upstream suffix>

This should make it clear which layer is targeting what BSP.

Build setup

Traditionally meta-mender-community has required board integrations to provide build setup configuration through the repo tool by Google. As it has a number of shortcomings, things are being moved to kas.

All submitted board integrations need to provide a build setup strategy. New repo-based setups will usually be rejected.

kas

For an introduction on kas, please see the tutorial article on the Mender Hub.

Building an image for a supported board

Quick start

To build an image using kas, you simply call it with the build verb and the desired configuration. Example for the Raspberry Pi 4, 64bit:

kas build meta-mender-community/kas/raspberrypi4-64.yml
A full getting started build procedure

Install the kas tool (optionally, you can install globally for all users. Run as root, respectively under sudo then):

pip install kas

Clone this repository:

git clone https://github.com/mendersoftware/meta-mender-community

Create a build directory and change into it:

mkdir -p meta-mender-community/my-build && cd meta-mender-community/my-build

Call kas to build for the Raspberry Pi 4, 64bit:

kas build ../kas/raspberrypi4-64.yml

The canonical build structure including resulting deployable images is located under meta-mender-community/my-build/build.

Adding a new build configuration

In the most straightforward case, a board integration can simply consist of a kas configuration file. Those are located in the kas top level directory.

Some relevant best practises:

  • if possible, common parts of board integrations should be factored out into includes. Those are located in the kas/include directory.
  • the mender-full.yml or mender-full-ubi.yml includes should be used as baseline
  • a minimal approach concerning image and DISTRO should be preferred
    • the default image is core-image-minimal, consider keeping it unless your platform has specific requirements
    • the default DISTRO is a nodistro, pure OpenEmbedded setup. While selecting a larger or custom DISTRO is acceptable, consider being as slim as possible to provide the highest degree of freedom to your users.

Requirements:

  • revisions of metadata layers defined in the configurations must be fixed. Exception: the master branch which tracks the Yocto Project / OpenEmbedded upstream
  • the primary targetted branch must be a Yocto Project LTS correlated one
  • add your board to the automated build configuration at .github/workflows/build.yml, marked as experimental. It will be moved out of experimental after a number of successful builds by the Mender team.

Google repo

Note: repo support is currently kept for compatibility reasons but will be removed in the future.

Manifest files

The google repo tool and associated manifest files are used for managing the list of repositories needed for these builds. The common manifests (meta-mender-community/scripts/mender.xml) is included by board-specific manifests and include the required Mender layers:

meta-mender-community/scripts/mender.xml

This includes the required Mender layers, meta-mender and meta-mender-community.

Each integration layer should provide a manifest file, e.g

meta-mender-community/meta-mender-sunxi/scripts/manifest-sunxi.xml

Templates and configuration fragments

To use this layer:

  1. Download the source:
    $ mkdir mender-<vendor/soc name>
    $ cd mender-<vendor/soc name>
    $ repo init \
           -u https://github.com/mendersoftware/meta-mender-community \
           -m meta-mender-<vendor/soc name>/scripts/manifest-<vendor/soc name>.xml \
           -b kirkstone
    $ repo sync
  1. Setup environment:
    $ . ./setup-environment <vendor/soc name>
  1. Build:
    $ bitbake core-image-base

The setup-environment script provided is a wrapper for the Yocto oe-init-build-env script.

Each integration layer must provide:

  • local.conf.append: this contains board-specific changes to be appended to the Yocto-generated local.conf file
  • bblayers.conf.sample: a template that will be copied to bblayers.conf
  • an entry in setup-environment

Contributing

We welcome and ask for your contribution. If you would like to contribute to Mender, please read our guide on how to best get started contributing code or documentation.

Community contributed layers will be co-maintained by the Mender team on a best-effort base. Coordination of reviews and merges happens case by case and based on responsiveness, respectively activity. Reviews and acknowledgements by the original contributors are explicitly not required for further contributions, in order to not block development and maintenance.

License

Mender is licensed under the Apache License, Version 2.0. See LICENSE for the full license text.

Connect with us

Authors

Mender was created by the team at Northern.tech AS, with many contributions from the community. Thanks everyone!

Mender is sponsored by Northern.tech AS.

meta-mender-community's People

Contributors

amsobr avatar chrisdimich avatar csonsino avatar drewmoseley avatar dwalkes avatar estape11 avatar fboudra avatar hesmar avatar jarrocha avatar jorisoffouga avatar jsolla avatar kacf avatar kekiefer avatar leon-anavi avatar lluiscampos avatar madisongh avatar mattes-bru avatar michaek avatar mirzak avatar moqmar avatar mrpelotazo avatar nandra avatar pgiangrossi avatar rickyricksanchez avatar superna9999 avatar texierp avatar themeaningfulengineer avatar theyoctojester avatar valks avatar zach-welch-aquabyte avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar

meta-mender-community's Issues

Mender upgrades across L4T releases (and yocto branches) are not currently supported

Partition layout changes on L4T releases have made this not trivial to support for older yocto branches.

Changes are coming with L4T version 32.6 which we may be able to leverage to upgrade from older branches, and no partition changes are planned from r32.5 (gatesgarth) forward at this time.

See OE4T meeting notes at this link and watch meeting updates in this link for more information.

See this sheet which tracks some combination of changes to partition layout between releases and has some references to associated xml files where these changes are tracked.

See this commit which backs out a feature to support u-boot environment partition migration between releases, which could be useful for TX2 u-boot based mender implementations.

OTA update from L4T 32.3.1 to 32.4.3

I hope this is the right place to post this:
I'm using a TX2, and meta-tegra zeus-l4t-32.3.1 , meta-mender zeus-v2020.06 and u-boot.
I built an artifact using meta-tegra dunfell-l4t-32.4.3 and meta-mender dunfell-v2020.10
A Mender (managed, not standalone) update with this artifact is successful:

{"level":"info","message":"Collected output (stderr) while running script /var/lib/mender/scripts/ArtifactCommit_Leave_20_printVolatileInfo
nvbootctrl dump-slots-info:
slot: 0,             priority: 14,             suffix: _a,             retry_count: 7,             boot_successful: 0
slot: 1,             priority: 15,             suffix: _b,             retry_count: 7,             boot_successful: 1
nvbootctrl get-current-slot:1
mender_boot_part=33
---------- end of script output","timestamp":"2020-11-16T18:32:16Z"}
/dev/mmcblk0p33 is used

But after another reboot, it switches back to the old partition:

slot: 0,            priority: 13,            suffix: _a,            retry_count: 7,            boot_successful: 0
slot: 1,            priority: 15,            suffix: _b,            retry_count: 7,            boot_successful: 1
current-slot 1
/dev/mmcblk0p1 is used
mender_boot_part=1

Issues with tegra nvbootctrl and unexpected slot errors

See post at https://hub.mender.io/t/failing-updates-on-tegra-tx2-due-to-issues-with-nvbootctrl/2765 and https://forums.developer.nvidia.com/t/nvbootctrl-get-current-slot-returning-unexpected-slot/156982/2

It appears boot slots are changing in some cases between mender updates for reasons unknown. When the boot slot gets out of sync with u-boot partitions bad things happen.

For TX2 this is a reason to make the mender build use PREFERRED_PROVIDER_virtual/bootloader = "cboot-prebuilt" as default as described at this link. It may not solve the problem completely but I think it will make the resulting situation less of a mess.

For Nano we are stuck with u-boot so we'll need to figure out how to handle this.

Delta upgrade issue when using cboot

Hi,

We recently started working on a new version of our device based on the Xavier NX module. By default, the meta-tegra layer configures this module to use cboot instead of UBoot.

To make this work with Mender, there is the custom libubootenv-fake scripts that are installed on the rootfs. However, when using delta updates, these are not sufficient. For more context, see https://hub.mender.io/t/delta-updates-checksum-mismatch/3312

Basically, what happens, is that the binary delta installer looks at mender_boot_part to determine which partition it should use as its base for applying the delta update. However, in the fake fw_printenv script, this will return nvbootctrl get-current-slot, essentially toggling between 0 or 1. The delta update then fails to apply because the checksum mismatches.

Would it be possible to modify this script to return the correct rootfs partition based on the slot? Or do you think this would trigger other issues? If you see no problems with this, I can try to make a pull request.

Thanks in advance,
Best regards,
Niels Avonds

Add support for Jetson Nano 2GB

As of OE4T/meta-tegra#452 the L4T release 32.4.4 is supported on the master branch of meta-tegra. This release should support the Nano 2GB, and support is in progress - see latest status at https://github.com/OE4T/meta-tegra/wiki/L4T-R32.4.4-Notes

There are no plans currently to backport support for r32.4.4 to dunfell or to upstream Nano 2GB support to meta-mender-community until L4T+next.

We are looking for community members who are interested in helping with adding/testing support for Nano 2GB. Please comment here if you would like to help.

failed to mounting ext4 file system using ext3 subsystem

Hi

I have prepare the tegraflash file using "bitbake demo-image-weston".
Build is successfully.
Now I have flash the SD card using "./dosdcard.sh", it is also success.

Now when I connect the SD Card to NVIDIA Tegra Jetson Xavier NX board, it is giving error
failed to mounting ext4 file system using ext3 subsystem
failed to mounting ext4 file system using ext2 subsystem

Can you please suggest what could be the problem?

Regards,

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.