TI: Add TI's custom debian repository and install a few packages by-default

[jsuhaas22]

Description

Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. List any dependencies that are required for this change.

TI maintains its own repository of debian packages here.

This PR adds this repository in TI images by-default through a new extension. So when the user performs apt update, apt install etc in Armbian images for TI boards, even TI's packages can be installed. Further, the PR also installs a few of TI's packages by-default in its images.

Additionally: it also changes TI's U-boot link from git.ti.com to Github.

How Has This Been Tested?

Please describe the tests that you ran to verify your changes. Please also note any relevant details for your test configuration.

This has been tested on SK-AM62B trixie image:

• [ ] boot test
• [ ] apt update and apt install tests

Checklist:

Please delete options that are not relevant.

• [ ] My code follows the style guidelines of this project
• [ ] I have performed a self-review of my own code
• [ ] I have commented my code, particularly in hard-to-understand areas
• [ ] My changes generate no new warnings

[coderabbitai[bot]]

"""

Walkthrough

This change updates the SK-AM62B board configuration by adding the CC33XX_SUPPORT variable. The K3 family source configuration is modified to update the BOOTSOURCE URL to a GitHub repository, enable the "ti-debpkgs" extension unconditionally, and conditionally manage TI-specific package lists and WiFi configuration based on release and support variables. A new script, ti-debpkgs.sh, is introduced with functions to add TI Debian packages to the root filesystem and configure the TI APT repository inside the chroot environment. Additionally, an APT pinning configuration file is added to prioritize packages from the Texas Instruments GitHub origin.

Suggested labels

ready to merge

Suggested reviewers

• glneo
• igorpecovnik """

✨ Finishing Touches

• [ ] 📝 Generate Docstrings

🧪 Generate Unit Tests

• [ ] Create PR with Unit Tests
• [ ] Commit Unit Tests in branch add-ti-debpkgs
• [ ] Post Copyable Unit Tests in Comment

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

• Review comments: Directly reply to a review comment made by CodeRabbit. Example:
  • I pushed a fix in commit <commit_id>, please review it.
  • Explain this complex logic.
  • Open a follow-up GitHub issue for this discussion.
• Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
  • @coderabbitai explain this code block.
  • @coderabbitai modularize this function.
• PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
  • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
  • @coderabbitai read src/utils.ts and explain its main purpose.
  • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
  • @coderabbitai help me debug CodeRabbit configuration file.

Support

Need help? Create a ticket on our support page for assistance with any issues or questions.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

• @coderabbitai pause to pause the reviews on a PR.
• @coderabbitai resume to resume the paused reviews.
• @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
• @coderabbitai full review to do a full review from scratch and review all the files again.
• @coderabbitai summary to regenerate the summary of the PR.
• @coderabbitai generate docstrings to generate docstrings for this PR.
• @coderabbitai generate sequence diagram to generate a sequence diagram of the changes in this PR.
• @coderabbitai auto-generate unit tests to generate unit tests for this PR.
• @coderabbitai resolve resolve all the CodeRabbit review comments.
• @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
• @coderabbitai help to get help.

Other keywords and placeholders

• Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
• Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
• Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

• You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
• Please see the configuration documentation for more information.
• If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

• Visit our Documentation for detailed information on how to use CodeRabbit.
• Join our Discord Community to get help, request features, and share feedback.
• Follow us on X/Twitter for updates and announcements.

[leggewie]

I think it would be beneficial to move this to APA

[igorpecovnik]

TI maintains its own repository of debian packages

Also there is alternative - auto mirroring to our main download infrastructure. https://github.com/armbian/os/wiki/Import-3rd-party-packages GitHub repository is not good in China mainland, while in this case it gets populated at https://docs.armbian.com/Mirrors/

I think it would be beneficial to move this to APA

Yes, that too.

[glneo]

This APA thing seems interesting. We host our deb packages on Github as we wanted a quick and easy way to host them, but it wasn't meant to be a long term solution. These packages are built for our Debian offering, which is now Armbian, so if there is a way to put them on the Armbian CDN we would be all for that.

Any plans for a build service for these (like Launchpad or Open Build Service)? Or is this supposed to only be a mirror service? For background, we currently build our source and binary deb packages from this repo[0] which simply fetches the source, adds the debian files based on the distro, then runs the normal dpkg-source/debuild tools. After that we have to take the packages and mess with Aptly to try to keep everything sorted before pushing to Github.

[0] https://github.com/TexasInstruments/debian-repos

[igorpecovnik]

if there is a way to put them on the Armbian CDN we would be all for that.

At this point, daily / hourly sync to apt.armbian.com and beta.armbian.com: https://github.com/armbian/os/wiki/Import-3rd-party-packages Examples: https://github.com/armbian/os/tree/main/external

Any plans for a build service

I think this will be possible trough APA, which will eventually be a part of main repository apt.armbian.com but @leggewie must tell how deep and far this is planned to be. And when.

[leggewie]

As of now, I didn't envision APA to be a build service. But hosting TI packages on APA, I'd be all for that.

@glneo The stuff in main should be dead-easy to bring over as from what I can see you already are providing the .dsc files etc. That stuff should be directly buildable in APA. As of now, APA is basically only there for package dependency logic, no truly compiled code is shipped and only very few files. But there's nothing to say APA could not do that in the future, it simply uses regular debian build tools same as you. The stuff in non-free is probably there because of NDA, I assume and as such source cannot be provided. You mention that you build everything with regular debian tooling so I believe it should be easy enough to merge your packages into APA (or something similar).

By the way, I see you are using reprepro for assembling the repository and that you do publish the conf and db directories. Those directories are generally not necessary for the published repository to function and it is generally discouraged to publish them for security reasons.

[glneo]

APA as a build service would be interesting, long term might even be a good way to offload the kernel/u-boot/etc package building done currently by build. Which could allow for a cleaner split between image building and package building at some point.

The packages in non-free are the couple binary-only packages we use (basically just the GPU driver and some firmware bits). We are working on open source GPU drivers in Mesa, and the firmware we will try to get into upstream linux-firmware, so these binary-only packages might not be needed in the future.

By the way, I see you are using reprepro for assembling the repository and that you do publish the conf and db directories. Those directories are generally not necessary for the published repository to function and it is generally strongly discouraged to publish them for security reasons.

Thanks for this info! @jsuhaas22 we should fix that

[leggewie]

I will shortly push a change to APA to declare an armbian-ti-common package where we can define packaging logic.

Please have a look at my wip-texasinstruments branch in APA for what I have in mind. I added your cx33* packages in Recommends but possibly Depends might be more appropriate.

[jsuhaas22]

@igorpecovnik and @leggewie

So if I understand correctly, the following is the list of TODO's right now, right?:

1. Move main/free packages to apt.armbian.com and beta.armbian.com
2. Let non-free packages remain in ti-debpkgs
3. Remove db and conf from ti-debpkgs
4. Add a TI virtual package in APA for mirroring

Is this correct?

In APA, I try to avoid special-casing distribution suites and I hope this would be no exception

The cc33* packages are meant only for Trixie. Our current main offering (even in past 2-3 releases) is Trixie, since TI's custom mesa packages have dependencies only found in Trixie, not Bookworm.

Please have a look at my wip-texasinstruments branch in APA for what I have in mind.

Thanks for doing this, @leggewie. Just a few comments:

1. cc33* packages aren't common for all boards. They are required only in 3 Sitara devices (2 of which aren't even supported in mainline armbian yet).
2. We should use Trixie instead of Bookworm

Anyway, I do get what you're saying, and I can take this up from here if you like.

[leggewie]

With regards to TODOs, I'd say moving your main packages to the armbian CDN is a possibility, not a necessity, certainly with the benefit of better China coverage. It can also happen at a later date, though, not connected to this PR. @igorpecovnik is the person to discuss that with. To add to the list, I'd say there are some changes to this PR in case you are happy with my suggestion to leverage APA and its extension instead of creating a new one. I've created a commit with what I believe are the appropriate changes on top of your PR. I haven't had the chance to test this, yet. After all, you may not like the idea or certain details.

The philosophy is that armbian-ti-common pulls in the necessary packages for you and it would do so liberally as long as it doesn't create problems. To help me understand; What happens when somebody tries to install the cc33* packages on an older release? On Ubuntu? On an SBC that doesn't have the necessary hardware? The way things currently stand in my proposal, the cc33* packages are in Recommends and there is no issue if they are unavailable or uninstallable for example due to unsatisfied libraries on an older release. You would need to make sure appropriate versioning of the dependencies is in place in your cc33* packages. They can be easily installed and uninstalled after flashing by the user and they can be pulled in via apt install --install-recommends=yes armbian-ti-common at any time. Armbian images install Recommends by default except for *-minimal images.

Depending on the situation, it might make sense to rename the armbian-ti-common package to armbian-bsp-k3 or even armbian-bsp-family-ti-k3 instead if that is more in line with what it would do.

I'll change the proposed sources.list.d snippet to trixie. https://raw.githubusercontent.com/TexasInstruments/ti-debpkgs/main/ti-debpkgs.sources as of now still points to bookworm which is where I copied that info.

[jsuhaas22]

I've created a commit with what I believe are the appropriate changes on top of your PR. I haven't had the chance to test this, yet. After all, you may not like the idea or certain details.

I do have a few concerns, below.

To help me understand; What happens when somebody tries to install the cc33* packages on an older release? On Ubuntu?

In our PPA, we have added it only to trixie, so if someone tries to install it on an older release or Ubuntu, it will just give a "Package not found" error.

On an SBC that doesn't have the necessary hardware?

It would lead to an unclean distribution, since the packages would be useless. Maybe the cc33xx-fw package could give some errors beyond that too, I am not sure. But other packages would be more harmful. For example, we have an out-of-tree module called ti-img-rogue-driver. This module has separate packages for each SBC, and uses dkms to bind itself to the kernel post-installation. So if we start installing too liberally, it would cause issues. Similarly, there are other non-free packages (including firmware) that are separate for each SBC too.

So having all of these in "armbian-ti-common" would be a bad idea. We would have to create a separate virtual package for each board.

Besides, too many unwanted common packages would lead to a very unclean rootfs. Not really sure we want that.

I'll change the proposed sources.list.d snippet to trixie. https://raw.githubusercontent.com/TexasInstruments/ti-debpkgs/main/ti-debpkgs.sources as of now still points to bookworm which is where I copied that info.

We release images with both, bookworm and trixie. For trixie, we just sed bookworm->trixie while building.