Skip to content

Commit 8c33bcd

Browse files
docs: add initial index and contributing guides
Not yet complete due missing arduino references, to be added once we include support for uno-q. Signed-off-by: Ricardo Salveti <[email protected]>
1 parent a6d8b9c commit 8c33bcd

File tree

2 files changed

+228
-0
lines changed

2 files changed

+228
-0
lines changed

docs/contributing.md

Lines changed: 172 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,172 @@
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+
- **Machine-specific packagegroups:**
93+
See [`meta-qcom/recipes-bsp/packagegroups`](https://github.com/qualcomm-linux/meta-qcom/tree/master/recipes-bsp/packagegroups)
94+
- **Partition definitions:**
95+
Use [`qcom-ptool`](https://github.com/qualcomm-linux/qcom-ptool) to manage partition layouts.
96+
- **Kernel enablement:**
97+
- Align with `linux-yocto-dev` and `linux-qcom-next`.
98+
- Patches should be **submitted upstream to the Linux kernel** first.
99+
- Temporary backports or in-flight patches are acceptable if tracked.
100+
References:
101+
- [Yocto kernel workflow](https://docs.yoctoproject.org/kernel-dev/index.html)
102+
- [Submitting Linux patches](https://www.kernel.org/doc/html/latest/process/submitting-patches.html)
103+
- **Firmware:**
104+
Custom firmware must be contributed to [`linux-firmware`](https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/) whenever possible.
105+
- **External layer recipes:**
106+
Changes targeting `oe-core` or `meta-openembedded` should be sent directly upstream.
107+
108+
---
109+
110+
## 4 Downstream Baseline – Qualcomm Linux 1.x
111+
112+
**Goal:** extend existing Qualcomm Linux 1.x releases with third-party hardware support equivalent to official EVKs.
113+
**Target branch:** `scarthgap` (≥ 1.4)
114+
115+
### 4.1 Expected Contribution Types
116+
117+
- Machine configuration files
118+
- Recipes for closed-source components
119+
(same binary-hosting rules as upstream)
120+
- Machine-specific packagegroups:
121+
[`meta-qcom-hwe/recipes-firmware/packagegroups`](https://github.com/qualcomm-linux/meta-qcom-hwe/tree/scarthgap/recipes-firmware/packagegroups)
122+
- Partition definitions:
123+
[`meta-qcom-hwe/recipes-devtools/partition-utils`](https://github.com/qualcomm-linux/meta-qcom-hwe/tree/scarthgap/recipes-devtools/partition-utils)
124+
- Kernel customization:
125+
Follow [`linux-qcom-base`](https://github.com/qualcomm-linux/meta-qcom-hwe/tree/scarthgap/recipes-kernel/linux)
126+
or `linux-qcom-custom` guidelines.
127+
- Machine-specific patches via `.bbappend`.
128+
- Custom kernel recipe forks only with maintainer consent.
129+
- Firmware additions:
130+
Extend [`linux-firmware` recipes](https://github.com/qualcomm-linux/meta-qcom-hwe/tree/scarthgap/recipes-firmware/firmware) as needed.
131+
- Hardware-specific enablement should **live entirely within this layer**, not in external “extras” layers or manifests.
132+
- Vendor-specific distro features / demo content belong in a **separate distro layer** maintained by the vendor.
133+
134+
---
135+
136+
## 5 Integration Expectations
137+
138+
- The repository should maintain **CI / CD** pipelines (GitHub Actions or kas CI) to validate new submissions.
139+
Reference: [kas-CI Documentation](https://kas.readthedocs.io/en/latest/userguide.html#kas-ci)
140+
- Vendors may optionally integrate with **LAVA** for runtime testing (get in contact with the project maintainers or raise an issue).
141+
Reference: [LAVA Framework](https://docs.lavasoftware.org/lava/index.html)
142+
143+
---
144+
145+
## 6 Machine Example – Arduino Uno-Q
146+
147+
*TODO*
148+
149+
The `Arduino Uno-Q` board serves as an example of a machine integration inside this layer.
150+
151+
Typical components include:
152+
- `conf/machine/arduino-unoq.conf`
153+
- Board-specific packagegroup under `recipes-bsp/packagegroups/`
154+
- Firmware recipes referencing vendor-hosted binaries
155+
- Partition configuration defined through `qcom-ptool`
156+
- Kernel support via `linux-qcom-next` `.bbappend`
157+
- CI job validating `core-image-minimal` build and boot on target
158+
159+
This structure should be mirrored by any new vendor machine added to the layer.
160+
161+
---
162+
163+
## 7 Additional References
164+
165+
- [Yocto Project Contributor Guide](https://docs.yoctoproject.org/dev/contributor-guide/index.html)
166+
- [OpenEmbedded Core Contributor Guide](https://wiki.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded)
167+
- [Yocto Layer Model and Compatibility](https://docs.yoctoproject.org/dev/layers.html)
168+
- [BitBake User Manual](https://docs.yoctoproject.org/bitbake/)
169+
170+
---
171+
172+
**SPDX-License-Identifier:** MIT

docs/index.md

Lines changed: 56 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,56 @@
1+
# meta-qcom-3rdparty Documentation
2+
3+
Welcome to the documentation for **meta-qcom-3rdparty**, an OpenEmbedded / Yocto layer that extends the Qualcomm Linux ecosystem by supporting community and vendor hardware platforms not officially maintained by Qualcomm.
4+
5+
This documentation is intended for developers, vendors, and contributors working with Qualcomm-based SoCs using the Yocto Project build system.
6+
7+
---
8+
9+
## Overview
10+
11+
The `meta-qcom-3rdparty` layer provides:
12+
13+
- Common BSP enablement for **third-party and community boards**
14+
- **Upstream-aligned** machine support based on `meta-qcom`
15+
- Clean, maintainable structure to avoid fragmentation across vendors
16+
- Integration hooks for both **Qualcomm Linux 1.x** (downstream) and future **Qualcomm Linux 2.x** (upstream) releases
17+
18+
---
19+
20+
## Documentation Index
21+
22+
- [Contribution Guidelines](contributing.md) — how to contribute patches, follow Yocto conventions, and structure vendor-specific code.
23+
- [Usage Guide](usage.md) — how to include and build the layer, add it to your workspace, and validate target builds (TODO).
24+
- [Supported Machines](supported-machines.md) — list of currently supported platforms, vendors, and hardware status (TODO).
25+
- [Developer Notes](developer.md) — additional details for maintainers, CI integration, and testing recommendations (TODO).
26+
27+
---
28+
29+
## Quick Start
30+
31+
To add this layer to your existing Yocto environment:
32+
33+
```bash
34+
git clone https://github.com/qualcomm-linux/meta-qcom-3rdparty.git
35+
bitbake-layers add-layer ../meta-qcom-3rdparty
36+
```
37+
38+
To build a reference image using [kas](https://kas.readthedocs.io/):
39+
40+
```bash
41+
kas build meta-qcom-3rdparty/ci/<machine.yml>
42+
```
43+
44+
---
45+
46+
## Related Layers and References
47+
48+
- [meta-qcom](https://github.com/qualcomm-linux/meta-qcom)
49+
- [meta-qcom-hwe](https://github.com/qualcomm-linux/meta-qcom-hwe)
50+
- [meta-qcom-distro](https://github.com/qualcomm-linux/meta-qcom-distro)
51+
- [OpenEmbedded Layer Index](https://layers.openembedded.org/layerindex/)
52+
- [Yocto Project Documentation](https://docs.yoctoproject.org/)
53+
54+
---
55+
56+
**SPDX-License-Identifier:** MIT

0 commit comments

Comments
 (0)