Skip to content

Conversation

@ricardosalveti
Copy link
Collaborator

No description provided.

Add link to the main README.md file, which is the entrypoint for our
documentation.

Signed-off-by: Ricardo Salveti <[email protected]>
Not yet complete due missing arduino references, to be added once we
include support for uno-q.

Signed-off-by: Ricardo Salveti <[email protected]>
Copy link

@angolini angolini left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great doc!
I add a comment regarding mentioning the Qualcomm Linux version, but it looks like it's inevitable to explicitly add the version, so maybe it can be ignored.

Because this layer expects to host multiple vendor platforms:
- Use **machine overrides** (`:machine` or `:append:machine`) to confine board-specific logic.
- Avoid cross-contamination between machines or with upstream `meta-qcom`.
- Do not introduce SoC-generic behavior under a machine-specific path.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we can add in this line something regarding upstreaming to meta-qcom, a suggestion would be:

Suggested change
- Do not introduce SoC-generic behavior under a machine-specific path.
- Do not introduce SoC-generic behavior under a machine-specific path. Those SoC-generic behavior must be sent/upstreamed to `meta-qcom` instead.

Comment on lines +70 to +71
- [`poky-altcfg`](https://git.yoctoproject.org/poky/tree/meta-poky/conf/distro/poky-altcfg.conf) (systemd-compatible)
- [`meta-qcom-distro`](https://github.com/qualcomm-linux/meta-qcom-distro)
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do we really prefer poky testing first? (I would invert the lines to make meta-qcom-distro appear as first suggestion, but it depends on what is tested by default

Comment on lines +75 to +76
- Each contributor acts as the **maintainer** of their changes, upstream and downstream.
- Vendors must appoint a **point-of-contact (PoC)** to review and triage vendor-specific PRs and issues promptly.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What does it mean exactly? The PoC's vendor is the person to merge the PR at the end? Is there a mantainers.md file with the list of people acting as maintainer and the person submitting the PR must include that person as reviewer?
I think elaboration is needed in this description


## 3 Upstream Baseline

**Goal:** upstream-aligned BSP enablement serving as the base for future Qualcomm Linux 2.0 releases.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we avoid using "2.0" here? It will be difficult to remember to update this file when 2.0 becomes something else


### 4.1 Expected Contribution Types

- Machine configuration files
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does it mean new machines are accepted in the "latest LTS based" branch, and it must only be supported by 1.4 or latter qualcomm linux version, in other words, in the latest LTS we can have new machines being included supporting not the latest qualcomm linux? (it it's higher or equal than 1.4, even thought the latest today is 1.6?)

- Firmware recipes referencing vendor-hosted binaries
- Partition configuration defined through `qcom-ptool`
- Kernel support via `linux-qcom-next` `.bbappend`
- CI job validating `core-image-minimal` build and boot on target
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I understand core-image-minimal does not include non-vital firmware, which can be binaries hosted on an vendor mirror. It means (I believe) that building only core-image-minimal will not detect missing closed firmware files. If this is the intended, so ok

Copy link

@kprosise kprosise left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No grammar/style issues that pop out, and Markdown appears to be properly formatted. Approved!

Copy link

@quaresmajose quaresmajose left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM


```bash
git clone https://github.com/qualcomm-linux/meta-qcom-3rdparty.git
bitbake-layers add-layer ../meta-qcom-3rdparty

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the user will use the kas maybe he doesn't need to take that step

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants