[dhavaljk]

No description provided.

[tleyrer]

ok

[pratheesh-ti]

/agentic_describe

[pratheesh-ti]

/agentic_review

[qodo-code-review]

PR Summary by Qodo

Add OpenPRU licensing and release manifest

📝 Documentation 🕐 10-20 Minutes

AI Description

• Replaces the standalone license entry point with a link to the release manifest.
• Adds OpenPRU release, licensing, export, provenance, and distribution disclosures.

Diagram

graph TD
  A["Repository User"] --> B["LICENSE.md"] --> C["Release Manifest"] --> D["License Details"]

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Retain a plain-text LICENSE

• ➕ Preserves automatic license detection by repository and packaging tools.
• ➕ Keeps BSD terms directly accessible without rendering HTML.
• ➕ Avoids making the generated manifest the sole source of license text.
• ➖ Duplicates license terms already embedded in the manifest.
• ➖ Requires both copies to remain synchronized when copyright details change.

Recommendation: Prefer retaining the standard BSD-3-Clause text in LICENSE while adding MANIFEST.html as a separate compliance artifact, with a link from README or the license file. This preserves tooling compatibility and immediate license visibility; use the PR's pointer-only approach only if TI compliance policy explicitly requires the manifest to be the sole entry point.

Files changed (2) +312 / -0

Documentation (2) +312 / -0

LICENSE.mdLink the license entry point to the manifest +1/-0

Link the license entry point to the manifest

• Adds a repository-level license document that directs readers to MANIFEST.html, replacing the deleted standalone BSD license file as the primary entry point.

LICENSE.md

MANIFEST.htmlAdd the OpenPRU release and licensing manifest +311/-0

Add the OpenPRU release and licensing manifest

• Adds a self-contained TI-styled manifest with release metadata, field definitions, export and link disclaimers, distribution details, provenance, and BSD-3-Clause terms. The manifest identifies OpenPRU version 2026.x under manifest ID SRAS00014772.

MANIFEST.html

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (2) 📘 Rule violations (0) 📜 Skill insights (0)

1. Package license link is broken 🐞 Bug ≡ Correctness ⭐ New

Description

LICENSE.md is added as the replacement license entry point, but
.metadata/.tirex/package.tirex.json still declares ../../LICENSE, which does not exist at the
repository root. Any package consumer following the declared license field reaches a missing file
instead of the new manifest link.

Code

LICENSE.md[1]

+[Manifest Document Link](./MANIFEST.html)

Evidence

The package descriptor declares ../../LICENSE as its license resource, while the replacement added
by this PR is named LICENSE.md; therefore the declared path cannot resolve to the new entry point.

.metadata/.tirex/package.tirex.json[7-10]
LICENSE.md[1-1]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The new license entry point is `LICENSE.md`, but package metadata still references the nonexistent root-level `LICENSE` file.

## Fix Focus Areas
- LICENSE.md[1-1]
- .metadata/.tirex/package.tirex.json[7-10]

## Recommended Fix
Change the package metadata license path from `../../LICENSE` to `../../LICENSE.md`, or retain a root-level `LICENSE` file at the currently declared path.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. The manifest omits required attributions 🐞 Bug ≡ Correctness

Description

The sole manifest row assigns BSD-3-Clause to [as installed]/* and reproduces only a 2022 Texas
Instruments notice, although bundled files carry IBM, Google, and Dimitar Dimitrov notices and the
documentation contains separate use restrictions. Distributions relying on this manifest therefore
misstate the rights for those files and can omit notices their licenses require.

Code

MANIFEST.html[R265-268]

+ 		<td><b>Location</b></td> 
+ 		<td id="location" name="location"> 
+ <span>[as installed]/*</span>
+ </td> 

Evidence

The manifest defines its wildcard notation as covering every file below the location and then
assigns [as installed]/* a single BSD-3-Clause entry with only a Texas Instruments notice.
Repository files within that scope explicitly require retention of notices belonging to IBM/Rusty
Russell, Google, and Dimitar Dimitrov, while the bundled compiler guide states additional
restrictions and grants no other license.

MANIFEST.html[95-101]
MANIFEST.html[249-268]
MANIFEST.html[294-297]
source/include/linux/pru_virtio_ring.h[7-33]
source/include/linux/rsc_types.h[1-18]
examples/gcc_rpmsg_echo_linux/Makefile[1-27]
docs_ai/reference/pru_optimizing_c_compiler_users_guide_v2_3/pru_optimizing_c_compiler_users_guide_v2_3.md[5814-5832]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The manifest applies one BSD-3-Clause entry and one Texas Instruments copyright notice to every installed file, despite bundled files having other copyright holders and licensing restrictions.
## Fix Focus Areas
- MANIFEST.html[249-297]
- source/include/linux/pru_virtio_ring.h[7-33]
- source/include/linux/rsc_types.h[1-18]
- examples/gcc_rpmsg_echo_linux/Makefile[1-27]
- docs_ai/reference/pru_optimizing_c_compiler_users_guide_v2_3/pru_optimizing_c_compiler_users_guide_v2_3.md[5814-5832]
## Recommended Fix
Replace the root-wide license row with accurately scoped entries for each distinct component and license. Include the required IBM, Google, and Dimitar Dimitrov notices, and list the documentation separately with its applicable Texas Instruments restrictions.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

3. Manifest metadata inconsistent ✗ Dismissed 🐞 Bug ≡ Correctness

Description

MANIFEST.html declares OpenPRU version 01.00.00 and license BSD-3-Clause, but package.json
declares version 07.03.00 and license BSD-2-Clause. This inconsistency can cause incorrect
compliance reporting and confusion about what license/version actually applies to the distributed
artifact.

Code

MANIFEST.html[R253-258]

+ 		<td id="version" name="version" rowspan="2"> 
+ <span>01.00.00</span>
+ </td> 
+ 		<td id="license" name="license" rowspan="2"> 
+ <span>BSD-3-Clause</span>
+ </td> 

Evidence

The manifest’s table explicitly lists the project version/license, and these values directly
contradict the package.json fields used by common tooling.

MANIFEST.html[250-258]
package.json[1-21]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`MANIFEST.html` reports a version and license identifier that conflict with the repository/package metadata.
## Issue Context
Automations often use `package.json` for version/license, while compliance teams may use the manifest; conflicting declarations create real compliance risk.
## Fix Focus Areas
- MANIFEST.html[250-258]
- package.json[1-21]
## Suggested fix
- Decide the authoritative license identifier (BSD-2-Clause vs BSD-3-Clause) and update *either* the manifest or `package.json` so they match.
- Update the manifest version (`01.00.00`) to match the repository/package version (`07.03.00`), or explain why the manifest is intentionally different (and then also update the manifest title/labels to make that explicit).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

View action required (2)

4. Invalid release date ✗ Dismissed 🐞 Bug ≡ Correctness

Description

MANIFEST.html uses 2024-28-02 as the release date, which is not a valid ISO-8601 date and will be
misinterpreted or rejected by parsers. This also appears inside a malformed heading block,
increasing the chance the release date is not rendered/parsed as intended.

Code

MANIFEST.html[R36-38]

+<h4 id="ReleaseDate">
+<span>2024-28-02</span>
+</h2>

Evidence

The release date string is shown as 2024-28-02, and the ` section is closed with `, indicating a
malformed block.

MANIFEST.html[30-42]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The manifest release date is not a valid date format (`2024-28-02`) and the surrounding heading tags are malformed.
## Issue Context
If this manifest is consumed by humans or tooling, date parsing and reliable DOM structure matters.
## Fix Focus Areas
- MANIFEST.html[36-39]
## Suggested fix
- Correct the date to the intended ISO format (e.g., `2024-02-28` if that’s what was intended).
- Ensure the heading tag is correctly closed (e.g., `<h4 ...>...</h4>`).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

5. License text removed ✗ Dismissed 🐞 Bug ≡ Correctness

Description

LICENSE.md now contains only a link to MANIFEST.html instead of the actual license terms, which will
break common license scanners/packagers that expect the license text in LICENSE*/COPYING* files.
This can cause downstream compliance and distribution checks to fail because the canonical license
text is no longer discoverable in a standard location.

Code

LICENSE.md[1]

+[Manifest Document Link](./MANIFEST.html)

Evidence

LICENSE.md contains only a hyperlink, while the BSD license text is embedded inside
MANIFEST.html, meaning the canonical license text is no longer present in a standard license file.

LICENSE.md[1-1]
MANIFEST.html[292-299]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The repo no longer exposes the project license text in a conventional root license file. `LICENSE.md` is currently just a link to `MANIFEST.html`, which many automated compliance tools will not parse.
## Issue Context
The license text exists only inside an HTML document, but standard tooling generally expects a plaintext license in `LICENSE`, `LICENSE.md`, or `COPYING`.
## Fix Focus Areas
- LICENSE.md[1-1]
- MANIFEST.html[292-299]
## Suggested fix
- Put the full BSD license text back into `LICENSE` or `LICENSE.md` (keep the manifest link as an additional reference if desired).
- If the manifest is required, keep it, but don’t make it the only place where the license terms live.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

6. Malformed manifest HTML ✗ Dismissed 🐞 Bug ⚙ Maintainability

Description

MANIFEST.html contains invalid HTML structures (mismatched heading close tags, repeated
id="content", and heading elements inside a table body), which can break layout and any DOM-based
parsing. If this document is meant for compliance review, malformed structure makes it harder to
reliably consume or validate.

Code

MANIFEST.html[R223-229]

+<!-- h3>Manifest Table</h3 -->
+<table > 
+<tbody> 
+ 
+ <h2> 
+ <span>OpenPRU Manifest Table</span>
+ </h2> 

Evidence

The document shows a ` closed with , multiple  blocks, and an  nested inside `, all of which
violate basic HTML structure.

MANIFEST.html[30-45]
MANIFEST.html[219-229]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The generated `MANIFEST.html` is not valid HTML in several places, which can cause inconsistent rendering/parsing.
## Issue Context
This file appears intended for human and/or automated consumption. Invalid DOM structure makes both error-prone.
## Fix Focus Areas
- MANIFEST.html[30-45]
- MANIFEST.html[219-229]
## Suggested fix
- Fix mismatched tag closures (e.g., `<h4>` must close with `</h4>`).
- Ensure unique IDs (replace repeated `id="content"` with classes or unique IDs).
- Remove block elements like `<h2>` from inside `<tbody>`; keep table structure as `<table><thead><tr>...` / `<tbody><tr>...`.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

Context sources

Review mode: ⚖️ Balanced: This push is documentation and manifest content, but it includes deletion of the repository license and a substantial hand-authored HTML/legal artifact with potentially important validity and licensing implications.

Tip of the day

💡 Did you know, you can group findings by type and pick your Finding display, from Minimal to Full

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

Previous reviews

Review updated until commit 013e522 ⚖️ Balanced

Results up to commit 7fecd8c ⚖️ Balanced

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

⚠️ 3 lower-priority findings omitted to fit the comment size limit; re-run the review or view the findings in the Qodo portal.

1. Invalid release date ✗ Dismissed 🐞 Bug ≡ Correctness

Description

MANIFEST.html uses 2024-28-02 as the release date, which is not a valid ISO-8601 date and will be
misinterpreted or rejected by parsers. This also appears inside a malformed heading block,
increasing the chance the release date is not rendered/parsed as intended.

Code

MANIFEST.html[R36-38]

+<h4 id="ReleaseDate">
+<span>2024-28-02</span>
+</h2>

Evidence

The release date string is shown as 2024-28-02, and the <h4> section is closed with </h2>,
indicating a malformed block.

MANIFEST.html[30-42]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The manifest release date is not a valid date format (`2024-28-02`) and the surrounding heading tags are malformed.

## Issue Context
If this manifest is consumed by humans or tooling, date parsing and reliable DOM structure matters.

## Fix Focus Areas
- MANIFEST.html[36-39]

## Suggested fix
- Correct the date to the intended ISO format (e.g., `2024-02-28` if that’s what was intended).
- Ensure the heading tag is correctly closed (e.g., `<h4 ...>...</h4>`).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. License text removed ✗ Dismissed 🐞 Bug ≡ Correctness

Description

LICENSE.md now contains only a link to MANIFEST.html instead of the actual license terms, which will
break common license scanners/packagers that expect the license text in LICENSE*/COPYING* files.
This can cause downstream compliance and distribution checks to fail because the canonical license
text is no longer discoverable in a standard location.

Code

LICENSE.md[1]

+[Manifest Document Link](./MANIFEST.html)

Evidence

LICENSE.md contains only a hyperlink, while the BSD license text is embedded inside
MANIFEST.html, meaning the canonical license text is no longer present in a standard license file.

LICENSE.md[1-1]
MANIFEST.html[292-299]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The repo no longer exposes the project license text in a conventional root license file. `LICENSE.md` is currently just a link to `MANIFEST.html`, which many automated compliance tools will not parse.

## Issue Context
The license text exists only inside an HTML document, but standard tooling generally expects a plaintext license in `LICENSE`, `LICENSE.md`, or `COPYING`.

## Fix Focus Areas
- LICENSE.md[1-1]
- MANIFEST.html[292-299]

## Suggested fix
- Put the full BSD license text back into `LICENSE` or `LICENSE.md` (keep the manifest link as an additional reference if desired).
- If the manifest is required, keep it, but don’t make it the only place where the license terms live.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

3. Manifest metadata inconsistent ✗ Dismissed 🐞 Bug ≡ Correctness

Description

MANIFEST.html declares OpenPRU version 01.00.00 and license BSD-3-Clause, but package.json
declares version 07.03.00 and license BSD-2-Clause. This inconsistency can cause incorrect
compliance reporting and confusion about what license/version actually applies to the distributed
artifact.

Code

MANIFEST.html[R253-258]

+ 		<td id="version" name="version" rowspan="2"> 
+ <span>01.00.00</span>
+ </td> 
+ 		<td id="license" name="license" rowspan="2"> 
+ <span>BSD-3-Clause</span>
+ </td> 

Evidence

The manifest’s table explicitly lists the project version/license, and these values directly
contradict the package.json fields used by common tooling.

MANIFEST.html[250-258]
package.json[1-21]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`MANIFEST.html` reports a version and license identifier that conflict with the repository/package metadata.

## Issue Context
Automations often use `package.json` for version/license, while compliance teams may use the manifest; conflicting declarations create real compliance risk.

## Fix Focus Areas
- MANIFEST.html[250-258]
- package.json[1-21]

## Suggested fix
- Decide the authoritative license identifier (BSD-2-Clause vs BSD-3-Clause) and update *either* the manifest or `package.json` so they match.
- Update the manifest version (`01.00.00`) to match the repository/package version (`07.03.00`), or explain why the manifest is intentionally different (and then also update the manifest title/labels to make that explicit).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

Results up to commit 5cf9cc3 ⚖️ Balanced

🐞 Bugs (1) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. The manifest omits required attributions 🐞 Bug ≡ Correctness

Description

The sole manifest row assigns BSD-3-Clause to [as installed]/* and reproduces only a 2022 Texas
Instruments notice, although bundled files carry IBM, Google, and Dimitar Dimitrov notices and the
documentation contains separate use restrictions. Distributions relying on this manifest therefore
misstate the rights for those files and can omit notices their licenses require.

Code

MANIFEST.html[R265-268]

+ 		<td><b>Location</b></td> 
+ 		<td id="location" name="location"> 
+ <span>[as installed]/*</span>
+ </td> 

Evidence

The manifest defines its wildcard notation as covering every file below the location and then
assigns [as installed]/* a single BSD-3-Clause entry with only a Texas Instruments notice.
Repository files within that scope explicitly require retention of notices belonging to IBM/Rusty
Russell, Google, and Dimitar Dimitrov, while the bundled compiler guide states additional
restrictions and grants no other license.

MANIFEST.html[95-101]
MANIFEST.html[249-268]
MANIFEST.html[294-297]
source/include/linux/pru_virtio_ring.h[7-33]
source/include/linux/rsc_types.h[1-18]
examples/gcc_rpmsg_echo_linux/Makefile[1-27]
docs_ai/reference/pru_optimizing_c_compiler_users_guide_v2_3/pru_optimizing_c_compiler_users_guide_v2_3.md[5814-5832]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The manifest applies one BSD-3-Clause entry and one Texas Instruments copyright notice to every installed file, despite bundled files having other copyright holders and licensing restrictions.

## Fix Focus Areas
- MANIFEST.html[249-297]
- source/include/linux/pru_virtio_ring.h[7-33]
- source/include/linux/rsc_types.h[1-18]
- examples/gcc_rpmsg_echo_linux/Makefile[1-27]
- docs_ai/reference/pru_optimizing_c_compiler_users_guide_v2_3/pru_optimizing_c_compiler_users_guide_v2_3.md[5814-5832]

## Recommended Fix
Replace the root-wide license row with accurately scoped entries for each distinct component and license. Include the required IBM, Google, and Dimitar Dimitrov notices, and list the documentation separately with its applicable Texas Instruments restrictions.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

[qodo-code-review]

Code review by qodo was updated up to the latest commit 5cf9cc3

[qodo-code-review]

Code review by qodo was updated up to the latest commit 013e522