|
| 1 | +# Contributing to meta-qcom-3rdparty |
| 2 | + |
| 3 | +This document describes how to contribute to the **Qualcomm Linux “meta-qcom-3rdparty”** layer and what standards are expected from contributors and vendors. |
| 4 | +It follows the same conventions used by the Yocto Project and OpenEmbedded upstream layers to ensure interoperability and quality. |
| 5 | + |
| 6 | +--- |
| 7 | + |
| 8 | +## 1 Purpose of this Repository |
| 9 | + |
| 10 | +The `meta-qcom-3rdparty` layer provides a **common OpenEmbedded / Yocto BSP** foundation for third-party hardware platforms based on Qualcomm SoCs. |
| 11 | + |
| 12 | +**Goals** |
| 13 | + |
| 14 | +- **Common layer for non-Qualcomm EVKs:** consolidate enablement for boards not officially maintained by Qualcomm. |
| 15 | +- **Clean BSP implementation:** a shared source of truth that vendors can reuse without divergence. |
| 16 | +- **Extend the Qualcomm Linux ecosystem:** encourage community participation and long-term maintainability aligned with `meta-qcom`. |
| 17 | + |
| 18 | +References: |
| 19 | +- [Yocto Project Overview](https://docs.yoctoproject.org/overview-manual/yp-intro.html) |
| 20 | +- [OpenEmbedded Layer Index](https://layers.openembedded.org/layerindex/) |
| 21 | + |
| 22 | +--- |
| 23 | + |
| 24 | +## 2 General Contribution Guidelines |
| 25 | + |
| 26 | +Our process mirrors the official Yocto Project contribution flow — see |
| 27 | +[Preparing Changes for Submission](https://docs.yoctoproject.org/dev/contributor-guide/submit-changes.html#preparing-changes-for-submission). |
| 28 | + |
| 29 | +### 2.1 Pull-Request Workflow |
| 30 | + |
| 31 | +- **Fork and propose changes** via GitHub Pull Requests. |
| 32 | + Use **draft mode** for work-in-progress patches. |
| 33 | +- **Create clean commits:** one logical change per commit. |
| 34 | + Follow [Yocto commit style](https://docs.yoctoproject.org/dev/contributor-guide/submit-changes.html#writing-good-commit-messages). |
| 35 | +- **Explain _why_** the change is needed in the commit message. |
| 36 | +- **Add a Signed-off-by line** to certify compliance with the [Developer’s Certificate of Origin](https://developercertificate.org/). |
| 37 | +- **Validate locally** before submission: build with `bitbake`, flash, and verify runtime. |
| 38 | +- **Address review feedback** and re-push to update your PR. |
| 39 | + Use `git rebase -i` to squash or reorder commits as needed. |
| 40 | + |
| 41 | +### 2.2 Machine-Specific Isolation |
| 42 | + |
| 43 | +Because this layer expects to host multiple vendor platforms: |
| 44 | +- Use **machine overrides** (`:machine` or `:append:machine`) to confine board-specific logic. |
| 45 | +- Avoid cross-contamination between machines or with upstream `meta-qcom`. |
| 46 | +- Do not introduce SoC-generic behavior under a machine-specific path. |
| 47 | + |
| 48 | +Reference: [BitBake Overrides](https://docs.yoctoproject.org/ref-manual/variables.html#var-OVERRIDES) |
| 49 | + |
| 50 | +### 2.3 Repository Organization |
| 51 | + |
| 52 | +All vendor boards live together in a single layer: |
| 53 | +- **No branch or folder segregation per vendor.** |
| 54 | +- Maintain quality equivalent to `meta-qcom`. |
| 55 | + |
| 56 | +### 2.4 No Recipe Forks |
| 57 | + |
| 58 | +- Forks of recipes from `meta-qcom`, `meta-qcom-hwe`, or base OE / Yocto layers are **not accepted**. |
| 59 | +- Use `.bbappend` files for vendor-specific patching. |
| 60 | +- Keep upstream recipes authoritative. |
| 61 | + |
| 62 | +Reference: [Understanding bbappends](https://docs.yoctoproject.org/ref-manual/terms.html#term-Append-Files) |
| 63 | + |
| 64 | +### 2.5 Scope of Changes |
| 65 | + |
| 66 | +- Limit changes to **BSP-specific content** (kernel, firmware, device tree, drivers, partition configs). |
| 67 | +- Avoid distribution-specific logic — vendors may ship separate distro layers. |
| 68 | + |
| 69 | +Preferred test distros: |
| 70 | +- [`poky-altcfg`](https://git.yoctoproject.org/poky/tree/meta-poky/conf/distro/poky-altcfg.conf) (systemd-compatible) |
| 71 | +- [`meta-qcom-distro`](https://github.com/qualcomm-linux/meta-qcom-distro) |
| 72 | + |
| 73 | +### 2.6 Maintainer Expectations |
| 74 | + |
| 75 | +- Each contributor acts as the **maintainer** of their changes, upstream and downstream. |
| 76 | +- Vendors must appoint a **point-of-contact (PoC)** to review and triage vendor-specific PRs and issues promptly. |
| 77 | + |
| 78 | +--- |
| 79 | + |
| 80 | +## 3 Upstream Baseline |
| 81 | + |
| 82 | +**Goal:** upstream-aligned BSP enablement serving as the base for future Qualcomm Linux 2.0 releases. |
| 83 | +**Target branch:** `main` |
| 84 | + |
| 85 | +### 3.1 Expected Contribution Types |
| 86 | + |
| 87 | +- **Machine configuration files** (`conf/machine/*.conf`) |
| 88 | +- **Closed-source component recipes** |
| 89 | + - Do **not** commit binaries. |
| 90 | + - Host them on a **public, no-login mirror** managed by the vendor. |
| 91 | + - Provide a clear `DESCRIPTION` and `LICENSE` field. |
| 92 | + Reference: [OE Best Practices for Binary Blobs](https://www.openembedded.org/wiki/Handling_Binary_Blobs) |
| 93 | +- **Machine-specific packagegroups:** |
| 94 | + See [`meta-qcom/recipes-bsp/packagegroups`](https://github.com/qualcomm-linux/meta-qcom/tree/master/recipes-bsp/packagegroups) |
| 95 | +- **Partition definitions:** |
| 96 | + Use [`qcom-ptool`](https://github.com/qualcomm-linux/qcom-ptool) to manage partition layouts. |
| 97 | +- **Kernel enablement:** |
| 98 | + - Align with `linux-yocto-dev` and `linux-qcom-next`. |
| 99 | + - Patches should be **submitted upstream to the Linux kernel** first. |
| 100 | + - Temporary backports or in-flight patches are acceptable if tracked. |
| 101 | + References: |
| 102 | + - [Yocto kernel workflow](https://docs.yoctoproject.org/kernel-dev/index.html) |
| 103 | + - [Submitting Linux patches](https://www.kernel.org/doc/html/latest/process/submitting-patches.html) |
| 104 | +- **Firmware:** |
| 105 | + Custom firmware must be contributed to [`linux-firmware`](https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/) whenever possible. |
| 106 | +- **External layer recipes:** |
| 107 | + Changes targeting `oe-core` or `meta-openembedded` should be sent directly upstream. |
| 108 | + |
| 109 | +--- |
| 110 | + |
| 111 | +## 4 Downstream Baseline – Qualcomm Linux 1.x |
| 112 | + |
| 113 | +**Goal:** extend existing Qualcomm Linux 1.x releases with third-party hardware support equivalent to official EVKs. |
| 114 | +**Target branch:** `scarthgap` (≥ 1.4) |
| 115 | + |
| 116 | +### 4.1 Expected Contribution Types |
| 117 | + |
| 118 | +- Machine configuration files |
| 119 | +- Recipes for closed-source components |
| 120 | + (same binary-hosting rules as upstream) |
| 121 | +- Machine-specific packagegroups: |
| 122 | + [`meta-qcom-hwe/recipes-firmware/packagegroups`](https://github.com/qualcomm-linux/meta-qcom-hwe/tree/scarthgap/recipes-firmware/packagegroups) |
| 123 | +- Partition definitions: |
| 124 | + [`meta-qcom-hwe/recipes-devtools/partition-utils`](https://github.com/qualcomm-linux/meta-qcom-hwe/tree/scarthgap/recipes-devtools/partition-utils) |
| 125 | +- Kernel customization: |
| 126 | + Follow [`linux-qcom-base`](https://github.com/qualcomm-linux/meta-qcom-hwe/tree/scarthgap/recipes-kernel/linux) |
| 127 | + or `linux-qcom-custom` guidelines. |
| 128 | + - Machine-specific patches via `.bbappend`. |
| 129 | + - Custom kernel recipe forks only with maintainer consent. |
| 130 | +- Firmware additions: |
| 131 | + Extend [`linux-firmware` recipes](https://github.com/qualcomm-linux/meta-qcom-hwe/tree/scarthgap/recipes-firmware/firmware) as needed. |
| 132 | +- Hardware-specific enablement should **live entirely within this layer**, not in external “extras” layers or manifests. |
| 133 | +- Vendor-specific distro features / demo content belong in a **separate distro layer** maintained by the vendor. |
| 134 | + |
| 135 | +--- |
| 136 | + |
| 137 | +## 5 Integration Expectations |
| 138 | + |
| 139 | +- The repository should maintain **CI / CD** pipelines (GitHub Actions or kas CI) to validate new submissions. |
| 140 | + Reference: [kas-CI Documentation](https://kas.readthedocs.io/en/latest/userguide.html#kas-ci) |
| 141 | +- Vendors may optionally integrate with **LAVA** for runtime testing (get in contact with the project maintainers or raise an issue). |
| 142 | + Reference: [LAVA Framework](https://docs.lavasoftware.org/lava/index.html) |
| 143 | + |
| 144 | +--- |
| 145 | + |
| 146 | +## 6 Machine Example – Arduino Uno-Q |
| 147 | + |
| 148 | +*TODO* |
| 149 | + |
| 150 | +The `Arduino Uno-Q` board serves as an example of a machine integration inside this layer. |
| 151 | + |
| 152 | +Typical components include: |
| 153 | +- `conf/machine/arduino-unoq.conf` |
| 154 | +- Board-specific packagegroup under `recipes-bsp/packagegroups/` |
| 155 | +- Firmware recipes referencing vendor-hosted binaries |
| 156 | +- Partition configuration defined through `qcom-ptool` |
| 157 | +- Kernel support via `linux-qcom-next` `.bbappend` |
| 158 | +- CI job validating `core-image-minimal` build and boot on target |
| 159 | + |
| 160 | +This structure should be mirrored by any new vendor machine added to the layer. |
| 161 | + |
| 162 | +--- |
| 163 | + |
| 164 | +## 7 Additional References |
| 165 | + |
| 166 | +- [Yocto Project Contributor Guide](https://docs.yoctoproject.org/dev/contributor-guide/index.html) |
| 167 | +- [OpenEmbedded Core Contributor Guide](https://wiki.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded) |
| 168 | +- [Yocto Layer Model and Compatibility](https://docs.yoctoproject.org/dev/layers.html) |
| 169 | +- [BitBake User Manual](https://docs.yoctoproject.org/bitbake/) |
| 170 | + |
| 171 | +--- |
| 172 | + |
| 173 | +**SPDX-License-Identifier:** MIT |
0 commit comments