-
-
Notifications
You must be signed in to change notification settings - Fork 2.6k
ti: Add more packages and make weston the OOB #8375
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
WalkthroughThis change updates board configuration files for SK-AM62B and SK-AM64B by introducing new configuration variables, including SoC identifiers and support flags for GPU, video output, Chromium, and additional firmware packages. The global TI package list in the K3 family configuration is expanded to include essential packages and conditionally appends GPU, video output, Chromium, and extra board-specific packages. Two new functions are added to the TI Debian packaging extension: one for user/service setup and configuration deployment, and another for activating DKMS modules after kernel installation. New configuration and PAM files are introduced for the emptty TTY manager and Weston compositor. The package list in the common CLI configuration is updated to include the Estimated code review effort🎯 2 (Simple) | ⏱️ ~7 minutes Suggested labels
Suggested reviewers
Note ⚡️ Unit Test Generation is now available in beta!Learn more here, or try it out under "Finishing Touches" below. 📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (8)
✅ Files skipped from review due to trivial changes (2)
🚧 Files skipped from review as they are similar to previous changes (6)
✨ Finishing Touches
🧪 Generate unit tests
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. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 5
🧹 Nitpick comments (3)
packages/bsp/ti/weston/weston.socket (1)
8-9
: Consider uncommenting user/group settings for security.Running Weston as root (implied by the commented user/group settings) may not be ideal from a security perspective. Consider uncommenting and using dedicated users if they exist on the system.
extensions/ti-debpkgs.sh (1)
45-45
: Consider improving error handling for service enablement.The current error handling only logs an alert if
systemctl enable
fails. Consider whether this should be a fatal error or if the alert provides sufficient information for debugging.packages/bsp/ti/weston/weston.service (1)
40-40
: Consider making Weston backend configurableThe service hard-codes the DRM backend with specific options. Consider making the backend and options configurable through the environment file for better flexibility across different hardware configurations.
-ExecStart=/usr/bin/weston --backend=drm-backend.so --continue-without-input --idle-time=0 +ExecStart=/usr/bin/weston $WESTON_OPTIONSThen define
WESTON_OPTIONS
in/etc/default/weston
.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (7)
config/boards/sk-am62b.conf
(1 hunks)config/boards/sk-am64b.conf
(1 hunks)config/sources/families/k3.conf
(1 hunks)extensions/ti-debpkgs.sh
(1 hunks)packages/bsp/ti/weston/weston
(1 hunks)packages/bsp/ti/weston/weston.service
(1 hunks)packages/bsp/ti/weston/weston.socket
(1 hunks)
🧰 Additional context used
🧠 Learnings (6)
📓 Common learnings
Learnt from: leggewie
PR: armbian/build#8357
File: config/boards/qcom-robotics-rb5.conf:88-88
Timestamp: 2025-07-04T18:33:19.873Z
Learning: In the Armbian build system, package transitions in Debian/Ubuntu don't happen uniformly across all releases. For example, the transition from plasma-workspace-wayland to plasma-workspace occurred in newer releases like trixie (Debian testing) around July 2024, but older releases like jammy (Ubuntu 22.04) still maintain the original plasma-workspace-wayland package. Release-specific package availability must be considered when updating package references.
Learnt from: libiunc
PR: armbian/build#8033
File: config/kernel/linux-starfive2-vendor.config:43-43
Timestamp: 2025-03-31T12:57:13.880Z
Learning: For StarFive2 platform kernel configurations, maintain alignment with vendor-provided configurations rather than modifying security settings like SECCOMP. This ensures hardware compatibility as intended by the manufacturer.
Learnt from: EvilOlaf
PR: armbian/build#0
File: :0-0
Timestamp: 2025-06-16T03:24:00.458Z
Learning: In Armbian board configuration files (.csc), the standard pattern is to have only one line as a comment describing the board hardware specifications. This single-line description typically includes the SoC model, core count, RAM options, and key features like connectivity options, storage interfaces, and special features.
Learnt from: Grippy98
PR: armbian/build#8202
File: config/desktop/trixie/environments/gnome/armbian/create_desktop_package.sh:2-3
Timestamp: 2025-05-16T15:34:34.672Z
Learning: The shell scripts in the Armbian build system's desktop configuration files, such as config/desktop/trixie/environments/gnome/armbian/create_desktop_package.sh, rely on environment variables like $SRC and $destination that are expected to be set externally before the script is executed.
Learnt from: pyavitz
PR: armbian/build#8361
File: config/kernel/linux-sunxi64-edge.config:594-597
Timestamp: 2025-07-06T16:27:45.349Z
Learning: In Armbian sunxi64-edge kernel configurations, PCI/PCIe support may be enabled for future-proofing purposes to support upcoming Allwinner SoCs like the T536 that include PCIe Gen2 interfaces, even if current primary targets like H616 lack PCIe controllers. This forward-looking approach prepares the configuration for next-generation hardware in the same SoC family.
Learnt from: Grippy98
PR: armbian/build#8152
File: lib/functions/configuration/interactive.sh:209-266
Timestamp: 2025-05-05T12:35:07.143Z
Learning: For the interactive kernel selection in Armbian, KERNEL_MAJOR_MINOR and KERNEL_DESCRIPTION are parsed from family.conf but deliberately not set as environment variables to avoid potential interference with other parts of the build system.
Learnt from: djurny
PR: armbian/build#8287
File: config/bootscripts/boot-sunxi.cmd:148-161
Timestamp: 2025-06-12T21:03:39.686Z
Learning: In Armbian U-Boot bootscripts, the `${cpu}` environment variable is always pre-set by U-Boot (or defaults to a valid value), so additional guards against it being unset are unnecessary.
packages/bsp/ti/weston/weston (1)
Learnt from: Grippy98
PR: armbian/build#8202
File: config/desktop/trixie/environments/gnome/armbian/create_desktop_package.sh:2-3
Timestamp: 2025-05-16T15:34:34.672Z
Learning: The shell scripts in the Armbian build system's desktop configuration files, such as config/desktop/trixie/environments/gnome/armbian/create_desktop_package.sh, rely on environment variables like $SRC and $destination that are expected to be set externally before the script is executed.
config/boards/sk-am62b.conf (2)
Learnt from: EvilOlaf
PR: armbian/build#0
File: :0-0
Timestamp: 2025-06-16T03:24:00.458Z
Learning: In Armbian board configuration files (.csc), the standard pattern is to have only one line as a comment describing the board hardware specifications. This single-line description typically includes the SoC model, core count, RAM options, and key features like connectivity options, storage interfaces, and special features.
Learnt from: pyavitz
PR: armbian/build#8361
File: config/kernel/linux-sunxi64-edge.config:594-597
Timestamp: 2025-07-06T16:27:45.349Z
Learning: In Armbian sunxi64-edge kernel configurations, PCI/PCIe support may be enabled for future-proofing purposes to support upcoming Allwinner SoCs like the T536 that include PCIe Gen2 interfaces, even if current primary targets like H616 lack PCIe controllers. This forward-looking approach prepares the configuration for next-generation hardware in the same SoC family.
config/boards/sk-am64b.conf (8)
Learnt from: EvilOlaf
PR: armbian/build#0
File: :0-0
Timestamp: 2025-06-16T03:24:00.458Z
Learning: In Armbian board configuration files (.csc), the standard pattern is to have only one line as a comment describing the board hardware specifications. This single-line description typically includes the SoC model, core count, RAM options, and key features like connectivity options, storage interfaces, and special features.
Learnt from: libiunc
PR: armbian/build#8033
File: config/kernel/linux-starfive2-vendor.config:43-43
Timestamp: 2025-03-31T12:57:13.880Z
Learning: For StarFive2 platform kernel configurations, maintain alignment with vendor-provided configurations rather than modifying security settings like SECCOMP. This ensures hardware compatibility as intended by the manufacturer.
Learnt from: EvilOlaf
PR: armbian/build#8330
File: config/sources/families/sun55iw3.conf:32-36
Timestamp: 2025-06-25T03:42:09.086Z
Learning: In Armbian build system configuration files like config/sources/families/*.conf, KERNELSOURCE is explicitly declared when using unofficial or 3rd party kernel repositories (like the "dev" branch using https://github.com/apritzel/linux), but can be omitted when using the standard mainline kernel (like the "edge" branch) since it will fall back to the default mainline source.
Learnt from: pyavitz
PR: armbian/build#8361
File: config/kernel/linux-sunxi64-edge.config:594-597
Timestamp: 2025-07-06T16:27:45.349Z
Learning: In Armbian sunxi64-edge kernel configurations, PCI/PCIe support may be enabled for future-proofing purposes to support upcoming Allwinner SoCs like the T536 that include PCIe Gen2 interfaces, even if current primary targets like H616 lack PCIe controllers. This forward-looking approach prepares the configuration for next-generation hardware in the same SoC family.
Learnt from: EvilOlaf
PR: armbian/build#8330
File: config/sources/families/sun55iw3.conf:32-36
Timestamp: 2025-06-25T03:40:52.109Z
Learning: In Armbian build system configuration files like config/sources/families/*.conf, when KERNELSOURCE is not explicitly declared in a case branch, the system falls back to a default KERNELSOURCE value, so missing KERNELSOURCE declarations are not critical issues.
Learnt from: djurny
PR: armbian/build#8272
File: config/bootscripts/boot-mvebu.cmd:182-186
Timestamp: 2025-06-04T23:45:38.860Z
Learning: In config/bootscripts/boot-mvebu.cmd, the `fdtfile` variable is mandatory for booting and is pre-set by U-Boot, but can be overridden via armbianEnv.txt. If `fdtfile` is empty, the subsequent device tree file search logic will eventually fail and trigger the critical error "Cannot find DT!" with proper error handling.
Learnt from: djurny
PR: armbian/build#8287
File: config/bootscripts/boot-sunxi.cmd:148-161
Timestamp: 2025-06-12T21:03:39.686Z
Learning: In Armbian U-Boot bootscripts, the `${cpu}` environment variable is always pre-set by U-Boot (or defaults to a valid value), so additional guards against it being unset are unnecessary.
Learnt from: djurny
PR: armbian/build#8287
File: config/bootscripts/boot-sunxi.cmd:13-23
Timestamp: 2025-06-12T21:08:11.318Z
Learning: In config/bootscripts/boot-sunxi.cmd the variable name `align_overlap_oboe_avoidance` intentionally uses the acronym “OBOE” (Off-By-One Error); it is not a typo and should not be renamed.
extensions/ti-debpkgs.sh (5)
Learnt from: leggewie
PR: armbian/build#8133
File: extensions/apa.sh:1-2
Timestamp: 2025-04-28T08:27:26.890Z
Learning: In the Armbian build system, extension scripts in the `extensions/` directory contain hook functions and are meant to be sourced, not executed directly. These scripts don't require a shebang or `set -euo pipefail`.
Learnt from: EvilOlaf
PR: armbian/build#8298
File: extensions/https_proxy.sh:1-9
Timestamp: 2025-06-14T05:53:10.627Z
Learning: In Armbian build framework, extensions are loaded and executed via lib/functions/general/extensions.sh using call_extension_method. The framework sets set -o errexit and set -o errtrace globally, and individual commands run with pipefail protection through the command execution functions.
Learnt from: Grippy98
PR: armbian/build#8202
File: config/desktop/trixie/environments/gnome/armbian/create_desktop_package.sh:2-3
Timestamp: 2025-05-16T15:34:34.672Z
Learning: The shell scripts in the Armbian build system's desktop configuration files, such as config/desktop/trixie/environments/gnome/armbian/create_desktop_package.sh, rely on environment variables like $SRC and $destination that are expected to be set externally before the script is executed.
Learnt from: djurny
PR: armbian/build#8315
File: lib/functions/rootfs/distro-agnostic.sh:54-68
Timestamp: 2025-06-22T00:45:26.182Z
Learning: In Armbian build system, external command dependencies like envsubst are handled by adding the required packages (e.g., gettext for envsubst) to host_dependencies in adaptative_prepare_host_dependencies function in lib/functions/host/prepare-host.sh, rather than checking command availability at runtime.
Learnt from: EvilOlaf
PR: armbian/build#8298
File: extensions/https_proxy.sh:1-9
Timestamp: 2025-06-14T05:53:10.627Z
Learning: Armbian build framework extensions are NOT designed to run standalone but are called by the supervisor. The framework provides environment variables like USERPATCHES_PATH and SDCARD, and commands are executed with protection via run_host_command_logged and chroot_sdcard functions that use bash -e -o pipefail.
config/sources/families/k3.conf (6)
Learnt from: EvilOlaf
PR: armbian/build#8330
File: config/sources/families/sun55iw3.conf:32-36
Timestamp: 2025-06-25T03:40:52.109Z
Learning: In Armbian build system configuration files like config/sources/families/*.conf, when KERNELSOURCE is not explicitly declared in a case branch, the system falls back to a default KERNELSOURCE value, so missing KERNELSOURCE declarations are not critical issues.
Learnt from: EvilOlaf
PR: armbian/build#8330
File: config/sources/families/sun55iw3.conf:32-36
Timestamp: 2025-06-25T03:42:09.086Z
Learning: In Armbian build system configuration files like config/sources/families/*.conf, KERNELSOURCE is explicitly declared when using unofficial or 3rd party kernel repositories (like the "dev" branch using https://github.com/apritzel/linux), but can be omitted when using the standard mainline kernel (like the "edge" branch) since it will fall back to the default mainline source.
Learnt from: Grippy98
PR: armbian/build#8152
File: lib/functions/configuration/interactive.sh:209-266
Timestamp: 2025-05-05T12:35:07.143Z
Learning: For the interactive kernel selection in Armbian, KERNEL_MAJOR_MINOR and KERNEL_DESCRIPTION are parsed from family.conf but deliberately not set as environment variables to avoid potential interference with other parts of the build system.
Learnt from: djurny
PR: armbian/build#8315
File: lib/functions/rootfs/distro-agnostic.sh:54-68
Timestamp: 2025-06-22T00:45:26.182Z
Learning: In Armbian build system, external command dependencies like envsubst are handled by adding the required packages (e.g., gettext for envsubst) to host_dependencies in adaptative_prepare_host_dependencies function in lib/functions/host/prepare-host.sh, rather than checking command availability at runtime.
Learnt from: Grippy98
PR: armbian/build#8202
File: config/desktop/trixie/environments/gnome/armbian/create_desktop_package.sh:2-3
Timestamp: 2025-05-16T15:34:34.672Z
Learning: The shell scripts in the Armbian build system's desktop configuration files, such as config/desktop/trixie/environments/gnome/armbian/create_desktop_package.sh, rely on environment variables like $SRC and $destination that are expected to be set externally before the script is executed.
Learnt from: leggewie
PR: armbian/build#8357
File: config/boards/qcom-robotics-rb5.conf:88-88
Timestamp: 2025-07-04T18:33:19.873Z
Learning: In the Armbian build system, package transitions in Debian/Ubuntu don't happen uniformly across all releases. For example, the transition from plasma-workspace-wayland to plasma-workspace occurred in newer releases like trixie (Debian testing) around July 2024, but older releases like jammy (Ubuntu 22.04) still maintain the original plasma-workspace-wayland package. Release-specific package availability must be considered when updating package references.
🧬 Code Graph Analysis (1)
extensions/ti-debpkgs.sh (3)
lib/functions/logging/runners.sh (2)
run_host_command_logged
(204-206)chroot_sdcard
(133-136).github/generate_CODEOWNERS.sh (1)
display_alert
(6-6)lib/functions/compilation/utils-compilation.sh (1)
grab_version
(23-32)
🔇 Additional comments (10)
packages/bsp/ti/weston/weston (1)
1-2
: Verify socket path consistency with weston.socket.The environment variables look correct for a system-level Weston service. However, there's a potential mismatch:
WAYLAND_DISPLAY=wayland-1
suggests the socket should be at/run/wayland-1
, but the correspondingweston.socket
file creates a socket at/run/wayland-0
.Please verify that the socket path and display name are consistent between this file and
weston.socket
.config/boards/sk-am62b.conf (1)
19-22
: LGTM! Feature flags are well-structured.The addition of GPU, display, and Chromium support flags follows Armbian conventions and integrates well with the broader TI package management changes in the k3 family configuration.
config/boards/sk-am64b.conf (1)
19-20
: LGTM! Board-specific configuration is appropriate.The SOC_ID and firmware package additions are consistent with the AM62B board configuration approach and properly specify AM64-specific PRU firmware packages.
extensions/ti-debpkgs.sh (1)
48-54
: LGTM! DKMS activation logic is sound.The function correctly:
- Checks the GPU_SUPPORT flag
- Uses the standard
grab_version
function- Constructs the kernel version string following Armbian conventions
- Runs DKMS autoinstall with appropriate verbosity
packages/bsp/ti/weston/weston.service (1)
34-34
:.not_logged_in_yet
Lifecycle Is Fully Handled
- Creation
- lib/functions/rootfs/distro-agnostic.sh:
touch "${SDCARD}"/root/.not_logged_in_yet
- extensions/preset-firstrun.sh: writes presets into
${SDCARD}/root/.not_logged_in_yet
for automated first-run configurations- Consumption
- etc/profile.d/armbian-check-first-login.sh and armbian-firstlogin: detect
/root/.not_logged_in_yet
to drive the first-login flow- Removal
- armbian-firstlogin (multiple places):
rm -f /root/.not_logged_in_yet
once setup completes- config/templates/customize-image.sh.template & extensions/cloud-init/cloud-init.sh: clean up leftover
.not_logged_in_yet
No further changes required.
config/sources/families/k3.conf (5)
23-23
: LGTM: Clean package array initializationThe TI_PACKAGES array is properly initialized with base packages. This provides a solid foundation for conditional package additions.
31-31
: SOC_ID definitions verifiedSOC_ID is defined in all relevant board configuration files, ensuring
${SOC_ID}
interpolates correctly ink3.conf
.• config/boards/sk-am64b.conf: SOC_ID="am64"
• config/boards/sk-am62b.conf: SOC_ID="am62"No further action required.
30-34
: Ensure GPU support packages exist on each target distributionThe TI GPU packages (
ti-img-rogue-driver-${SOC_ID}-dkms
,ti-img-rogue-umlibs-${SOC_ID}
,ti-img-rogue-tools-${SOC_ID}
,ti-img-rogue-firmware-${SOC_ID}
, plusmesa-vulkan-drivers
,libgl1-mesa-dri
,gstreamer1.0-*
) may be named differently or missing in some distros. Add distribution-specific checks before appending them toTI_PACKAGES
. For example:• Detect the distro via
/etc/os-release
and dispatch accordingly
• Debian/Ubuntu:apt-cache policy "$pkg" &>/dev/null || missing+=("$pkg")• RHEL/CentOS/Fedora:
dnf repoquery --quiet --exactmatch "$pkg" || missing+=("$pkg")• Report any missing packages and skip or substitute as needed
Example snippet:
. /etc/os-release if [[ "${GPU_SUPPORT}" == "yes" ]] ; then + missing=() + add_pkg(){ + local pkg=$1 + case "$ID" in + debian|ubuntu) apt-cache policy "$pkg" &>/dev/null ;; + centos|rhel|fedora) dnf repoquery --quiet --exactmatch "$pkg" ;; + *) return 1 ;; + esac || missing+=("$pkg") + TI_PACKAGES+=("$pkg") + } + # TI image drivers - TI_PACKAGES+=("ti-img-rogue-driver-${SOC_ID}-dkms" "ti-img-rogue-umlibs-${SOC_ID}" "ti-img-rogue-tools-${SOC_ID}" "ti-img-rogue-firmware-${SOC_ID}") + for pkg in \ + "ti-img-rogue-driver-${SOC_ID}-dkms" \ + "ti-img-rogue-umlibs-${SOC_ID}" \ + "ti-img-rogue-tools-${SOC_ID}" \ + "ti-img-rogue-firmware-${SOC_ID}"; do + add_pkg "$pkg" + done + # Mesa / Vulkan - TI_PACKAGES+=("mesa-vulkan-drivers" "libgl1-mesa-dri") + for pkg in "mesa-vulkan-drivers" "libgl1-mesa-dri"; do + add_pkg "$pkg" + done + # GStreamer - TI_PACKAGES+=("gstreamer1.0-tools" "gstreamer1.0-plugins-good" "gstreamer1.0-plugins-bad" "gstreamer1.0-plugins-base") + for pkg in \ + "gstreamer1.0-tools" \ + "gstreamer1.0-plugins-good" \ + "gstreamer1.0-plugins-bad" \ + "gstreamer1.0-plugins-base"; do + add_pkg "$pkg" + done + + if [[ ${#missing[@]} -gt 0 ]]; then + echo "Warning: the following GPU packages are unavailable on $ID: ${missing[*]}" + fi fiPlease verify these package names against your TI repositories on each supported distribution.
46-48
: Improve array handling for EXTRA_BOARD_PACKAGESThe current syntax
"${EXTRA_BOARD_PACKAGES[@]}"
within the TI_PACKAGES+=() assignment may not work correctly if EXTRA_BOARD_PACKAGES is not an array. Consider using a more robust approach.-if [[ ! -z ${EXTRA_BOARD_PACKAGES} ]] ; then - TI_PACKAGES+=("${EXTRA_BOARD_PACKAGES[@]}") -fi +if [[ -n "${EXTRA_BOARD_PACKAGES}" ]] ; then + if [[ "$(declare -p EXTRA_BOARD_PACKAGES 2>/dev/null)" =~ "declare -a" ]] ; then + TI_PACKAGES+=("${EXTRA_BOARD_PACKAGES[@]}") + else + TI_PACKAGES+=("${EXTRA_BOARD_PACKAGES}") + fi +fiThis handles both string and array cases properly.
⛔ Skipped due to learnings
Learnt from: djurny PR: armbian/build#8166 File: config/bootscripts/boot-mvebu.cmd:38-50 Timestamp: 2025-05-07T20:49:40.969Z Learning: In U-Boot scripts, `itest.s` should be used for explicit string comparisons rather than plain `itest` with string operators like `==`.
Learnt from: djurny PR: armbian/build#8315 File: lib/functions/rootfs/distro-agnostic.sh:54-68 Timestamp: 2025-06-22T00:45:26.182Z Learning: In Armbian build system, external command dependencies like envsubst are handled by adding the required packages (e.g., gettext for envsubst) to host_dependencies in adaptative_prepare_host_dependencies function in lib/functions/host/prepare-host.sh, rather than checking command availability at runtime.
44-44
: Action Required: Verify k3 family inclusion and firmware package namesEnsure
config/sources/families/k3.conf
is actually applied to each k3-based board and that the SOC_ID interpolation produces valid firmware package names. Based on the current board configs:
- config/boards/sk-am64b.conf → SOC_ID="am64" → would generate
firmware-ti-ipc-am64
- config/boards/sk-am62b.conf → SOC_ID="am62" → would generate
firmware-ti-ipc-am62
Please confirm:
- That
k3.conf
is sourced (directly or via common include) in each of these board files- The interpolated packages (
firmware-ti-ipc-am64
,firmware-ti-ipc-am62
) actually exist and match your firmware repository naming
packages/bsp/ti/weston/weston.socket
Outdated
RequiresMountsFor=/run | ||
|
||
[Socket] | ||
ListenStream=/run/wayland-0 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fix socket path mismatch with environment configuration.
The socket path /run/wayland-0
doesn't match the WAYLAND_DISPLAY=wayland-1
setting in the weston
environment file. This will cause connection failures.
Choose one of these solutions:
- Change the socket path to match the display name:
-ListenStream=/run/wayland-0
+ListenStream=/run/wayland-1
- Or change the environment variable to match the socket:
-WAYLAND_DISPLAY=wayland-1
+WAYLAND_DISPLAY=wayland-0
Committable suggestion skipped: line range outside the PR's diff.
🤖 Prompt for AI Agents
In packages/bsp/ti/weston/weston.socket at line 6, the socket path
ListenStream=/run/wayland-0 does not match the WAYLAND_DISPLAY=wayland-1
environment setting, causing connection failures. Fix this by either updating
the socket path to /run/wayland-1 to match the environment variable or change
the WAYLAND_DISPLAY environment variable to wayland-0 to match the socket path,
ensuring both are consistent.
extensions/ti-debpkgs.sh
Outdated
@@ -35,3 +35,20 @@ function custom_apt_repo__install_ti_packages() { | |||
display_alert "Valid Options Would Have Been: ${valid_suites[@]}" | |||
fi | |||
} | |||
|
|||
function pre_customize_image__enable_services() { | |||
run_host_command_logged "mkdir -p $DEST/lib/systemd/system/" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fix incorrect path variable.
The mkdir
command uses $DEST
but should use $SDCARD
to be consistent with the rest of the function and the Armbian build system conventions.
- run_host_command_logged "mkdir -p $DEST/lib/systemd/system/"
+ run_host_command_logged "mkdir -p $SDCARD/lib/systemd/system/"
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
run_host_command_logged "mkdir -p $DEST/lib/systemd/system/" | |
- run_host_command_logged "mkdir -p $DEST/lib/systemd/system/" | |
+ run_host_command_logged "mkdir -p $SDCARD/lib/systemd/system/" |
🤖 Prompt for AI Agents
In extensions/ti-debpkgs.sh at line 40, the mkdir command incorrectly uses the
$DEST variable for the path, but it should use $SDCARD to align with the rest of
the function and Armbian build system conventions. Replace $DEST with $SDCARD in
the mkdir command to fix the path variable usage.
User=root | ||
Group=root |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Security concern: Running Weston as root user
Running the Weston compositor as root presents significant security risks. Display servers typically run with lower privileges for security isolation. Consider creating a dedicated user account for Weston or using a login manager that can handle privilege separation.
Consider this approach instead:
-User=root
-Group=root
+User=weston
+Group=weston
And ensure the weston user is created with appropriate permissions for accessing graphics hardware.
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
User=root | |
Group=root | |
User=weston | |
Group=weston |
🤖 Prompt for AI Agents
In packages/bsp/ti/weston/weston.service at lines 47 to 48, the service is
configured to run Weston as the root user, which poses security risks. Modify
the User and Group directives to run Weston under a dedicated, non-root user
account (e.g., 'weston'). Ensure this user is created beforehand with the
necessary permissions to access graphics hardware, and update the service file
accordingly to enhance security by limiting privileges.
WorkingDirectory=/root/ | ||
|
||
# Set up a full user session for the user, required by Weston. | ||
PAMName=weston-autologin |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
💡 Verification agent
🧩 Analysis chain
Verify PAM configuration for weston-autologin
The service references a PAM configuration named "weston-autologin" but this PAM configuration file is not provided in the PR. Without proper PAM configuration, the service may fail to start.
Please ensure the corresponding PAM configuration file exists:
🏁 Script executed:
#!/bin/bash
# Description: Check if PAM configuration for weston-autologin exists
# Expected: PAM config file should exist and be properly configured
fd -t f "weston-autologin" /etc/pam.d/
Length of output: 137
🏁 Script executed:
#!/bin/bash
set -e
echo "Searching for pam.d directories in the repository:"
fd -t d pam.d .
echo
echo "Searching for files named 'weston-autologin' in the repository:"
fd -t f weston-autologin .
echo
echo "Searching for occurrences of 'weston-autologin' in file contents:"
rg -n "weston-autologin"
Length of output: 563
Add missing PAM configuration for “weston-autologin”
The service unit at packages/bsp/ti/weston/weston.service
(line 54) specifies
PAMName=weston-autologin
but no corresponding PAM config file (pam.d/weston-autologin
) is present in this PR. Without it, the service will fail to start.
• Please add the PAM configuration file under your package’s pam.d/
directory (e.g. files/etc/pam.d/weston-autologin
) with the required rules.
• Verify that it’s installed to /etc/pam.d/weston-autologin
on target systems.
🤖 Prompt for AI Agents
In packages/bsp/ti/weston/weston.service at line 54, the PAMName is set to
"weston-autologin" but the corresponding PAM configuration file
pam.d/weston-autologin is missing. To fix this, create the PAM config file with
the necessary authentication rules under your package's pam.d/ directory (e.g.,
files/etc/pam.d/weston-autologin) and ensure it is installed to
/etc/pam.d/weston-autologin on the target system.
[Service] | ||
# Requires systemd-notify.so Weston plugin. | ||
Type=simple | ||
EnvironmentFile=/etc/default/weston |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
💡 Verification agent
❓ Verification inconclusive
Verify weston environment file
The service references /etc/default/weston
but this environment file is not provided in the PR. Missing environment configuration could cause the service to fail or behave unexpectedly.
Please ensure the weston environment file exists:
🏁 Script executed:
#!/bin/bash
# Description: Check for weston environment file
# Expected: Environment file should exist with proper variables
fd -t f "weston" /etc/default/
Length of output: 131
🏁 Script executed:
#!/bin/bash
# Search for the weston environment file within the repository
find . -type f | grep '/etc/default/weston$'
Length of output: 46
Provide Weston environment file or remove unused reference
The weston.service
unit at packages/bsp/ti/weston/weston.service
still references an external file:
39 │ EnvironmentFile=/etc/default/weston
However, no /etc/default/weston
is present in the repo or packaging. This can cause the service to fail or skip needed settings.
Please address one of the following:
-
Include the default environment file
Add a file (e.g.packages/bsp/ti/weston/weston.env
) and install it to/etc/default/weston
with the necessary variables for Weston. -
Remove or adjust the
EnvironmentFile=
directive
If Weston doesn’t require custom environment variables, drop or comment out the line to avoid loading a non-existent file.
🤖 Prompt for AI Agents
In packages/bsp/ti/weston/weston.service at line 39, the EnvironmentFile
directive points to /etc/default/weston, which does not exist in the repo or
packaging. To fix this, either create a default environment file with necessary
Weston variables (e.g., packages/bsp/ti/weston/weston.env) and ensure it is
installed to /etc/default/weston, or remove/comment out the EnvironmentFile line
if no custom environment variables are needed to prevent service failure.
Starting Weston as a root systemd service was a hack we did for our Yocto SDK distro, it was not correct and we are switching to using a proper weston user and launching with a login-manager (Emptty). For Armbian you should do the same or re-use GDM or similar default manager to launch a weston session. |
@glneo Understood. I am going with emptty, and got it working using the upstream emptty package. Do we want auto-login into weston like in our Yocto-based SDK, or do we want to show the username/password screen? I am wondering since the first boot takes you through the armbian-firstlogin script setup anyway. For now, I have gone with auto-login. If you think the alternative is better, I will update the PR. |
781005f
to
e0e9e5d
Compare
TI_PACKAGES+=("weston" "emptty") | ||
fi | ||
|
||
if [[ "${CHROMIUM_SUPPORT}" == "yes" ]] ; then |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For my own knowledge here - when would we have GPU support but no Chromium support currently?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Currently, this is the case with AM62SIP and AM62LP. This is due to memory constraints (at least in case of SIP).
config/boards/sk-am62b.conf
Outdated
@@ -16,3 +16,7 @@ ATF_BOARD="lite" | |||
OPTEE_ARGS="CFG_TEE_CORE_LOG_LEVEL=1" | |||
OPTEE_PLATFORM="k3-am62x" | |||
CC33XX_SUPPORT="yes" | |||
GPU_SUPPORT="yes" | |||
SOC_ID="am62" | |||
DISPLAY_SUPPORT="yes" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is already HAS_VIDEO_OUTPUT
which if not set to no
is assumed to be true, you should be able to make use of that instead.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
assumed to be true
The files in lib/ just check if its set to "no", but don't check if its "yes" anywhere (i.e. they don't really initialize it anywhere to "yes"). So I have set it to "yes" explicitly in sk-am62b.conf.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it would be easier to assume it to be true in the check you are adding, only one of our boards will have it set as "no", for all others just add the display support.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done
e0e9e5d
to
8399056
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 2
🧹 Nitpick comments (1)
extensions/ti-debpkgs.sh (1)
44-50
: Quote variable expansions and verify destination paths
$SRC
and$SDCARD
are unquoted inside thecp
/mkdir
command strings.
A pathname with spaces (rare, but possible in$SRC
) would break the command passed to the host shell.The Weston/Emptty configuration copies can be compacted, but more importantly, should be fully quoted:
- run_host_command_logged "cp -v $SRC/packages/bsp/ti/emptty/weston.ini $SDCARD/etc/xdg/weston/" + run_host_command_logged "cp -v \"${SRC}/packages/bsp/ti/emptty/weston.ini\" \"${SDCARD}/etc/xdg/weston/\""(repeat for the other two
cp
lines).
- Double-check that Emptty actually expects its main config at
/etc/emptty/conf
.
Upstream recently switched the default to/etc/emptty/emptty.conf
; if that’s the case the copy target should be updated accordingly.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (8)
config/boards/sk-am62b.conf
(1 hunks)config/boards/sk-am64b.conf
(1 hunks)config/cli/common/main/packages
(1 hunks)config/sources/families/k3.conf
(1 hunks)extensions/ti-debpkgs.sh
(1 hunks)packages/bsp/ti/emptty/emptty.conf
(1 hunks)packages/bsp/ti/emptty/pamconf
(1 hunks)packages/bsp/ti/emptty/weston.ini
(1 hunks)
✅ Files skipped from review due to trivial changes (2)
- config/cli/common/main/packages
- packages/bsp/ti/emptty/emptty.conf
🚧 Files skipped from review as they are similar to previous changes (5)
- packages/bsp/ti/emptty/weston.ini
- config/boards/sk-am62b.conf
- packages/bsp/ti/emptty/pamconf
- config/boards/sk-am64b.conf
- config/sources/families/k3.conf
🧰 Additional context used
🧠 Learnings (2)
📓 Common learnings
Learnt from: EvilOlaf
PR: armbian/build#8428
File: config/boards/lckfb-taishanpi.csc:5-9
Timestamp: 2025-07-25T03:51:50.830Z
Learning: When reviewing PRs in the Armbian build system, U-Boot defconfig files and patches may be added as part of the PR changes but might not be visible in the current repository clone state during review. It's important to check the actual PR file changes directly via GitHub or the PR API to get the complete picture of what files are being added or modified.
Learnt from: EvilOlaf
PR: armbian/build#8428
File: config/boards/lckfb-taishanpi.csc:5-9
Timestamp: 2025-07-25T03:51:50.830Z
Learning: When reviewing PRs in the Armbian build system, U-Boot defconfig files and patches may be added as part of the PR changes but might not be visible in the current repository clone state during review. It's important to check the actual PR file changes directly via GitHub API (https://api.github.com/repos/armbian/build/pulls/{pr_number}/files) to get the complete picture of what files are being added or modified, especially for U-Boot patches that will be applied during the build process.
Learnt from: leggewie
PR: armbian/build#8357
File: config/boards/qcom-robotics-rb5.conf:88-88
Timestamp: 2025-07-04T18:33:19.873Z
Learning: In the Armbian build system, package transitions in Debian/Ubuntu don't happen uniformly across all releases. For example, the transition from plasma-workspace-wayland to plasma-workspace occurred in newer releases like trixie (Debian testing) around July 2024, but older releases like jammy (Ubuntu 22.04) still maintain the original plasma-workspace-wayland package. Release-specific package availability must be considered when updating package references.
Learnt from: libiunc
PR: armbian/build#8033
File: config/kernel/linux-starfive2-vendor.config:43-43
Timestamp: 2025-03-31T12:57:13.880Z
Learning: For StarFive2 platform kernel configurations, maintain alignment with vendor-provided configurations rather than modifying security settings like SECCOMP. This ensures hardware compatibility as intended by the manufacturer.
Learnt from: EvilOlaf
PR: armbian/build#0
File: :0-0
Timestamp: 2025-06-16T03:24:00.458Z
Learning: In Armbian board configuration files (.csc), the standard pattern is to have only one line as a comment describing the board hardware specifications. This single-line description typically includes the SoC model, core count, RAM options, and key features like connectivity options, storage interfaces, and special features.
Learnt from: pyavitz
PR: armbian/build#8388
File: config/boards/kickpik2b.conf:1-14
Timestamp: 2025-07-17T04:12:33.125Z
Learning: In the Armbian build system, board configuration files (*.conf) follow a project standard of not including shebang lines, even though they contain bash code and are sourced by the build system. This is an established Armbian convention that individual contributors are expected to follow, and changes to this standard would require broader project maintainer approval.
Learnt from: pyavitz
PR: armbian/build#8421
File: config/kernel/linux-sunxi64-edge.config:805-825
Timestamp: 2025-07-27T15:53:30.629Z
Learning: In the Armbian build system, kernel configurations prioritize broad hardware compatibility over optimization concerns. Even when including numerous legacy/obsolete drivers causes technical issues like increased initramfs size and slower enumeration, the project philosophy is to "appease the masses" by ensuring maximum device compatibility rather than optimizing for specific use cases.
Learnt from: EvilOlaf
PR: armbian/build#8417
File: config/boards/orangepi5pro.csc:57-58
Timestamp: 2025-07-23T07:30:52.265Z
Learning: In the Armbian build system, BOOTPATCHDIR can contain board-specific subdirectories (e.g., board_orangepi5pro) for applying patches to specific boards only. The framework automatically checks if such board-specific subdirectories exist for the board being built and applies those patches accordingly.
Learnt from: EvilOlaf
PR: armbian/build#0
File: :0-0
Timestamp: 2025-07-21T04:12:02.439Z
Learning: In the Armbian build system, for recurring maintenance tasks like kernel version bumping, TODO comments should use generic version formats (e.g., "MAJOR.MINOR-rc1") rather than specific version numbers (e.g., "6.17-rc1") to avoid the need for frequent comment updates that would create unnecessary maintenance overhead.
Learnt from: Grippy98
PR: armbian/build#8152
File: lib/functions/configuration/interactive.sh:209-266
Timestamp: 2025-05-05T12:35:07.143Z
Learning: For the interactive kernel selection in Armbian, KERNEL_MAJOR_MINOR and KERNEL_DESCRIPTION are parsed from family.conf but deliberately not set as environment variables to avoid potential interference with other parts of the build system.
Learnt from: EvilOlaf
PR: armbian/build#8330
File: config/sources/families/sun55iw3.conf:32-36
Timestamp: 2025-06-25T03:42:09.086Z
Learning: In Armbian build system configuration files like config/sources/families/*.conf, KERNELSOURCE is explicitly declared when using unofficial or 3rd party kernel repositories (like the "dev" branch using https://github.com/apritzel/linux), but can be omitted when using the standard mainline kernel (like the "edge" branch) since it will fall back to the default mainline source.
Learnt from: Grippy98
PR: armbian/build#8202
File: config/desktop/trixie/environments/gnome/armbian/create_desktop_package.sh:2-3
Timestamp: 2025-05-16T15:34:34.672Z
Learning: The shell scripts in the Armbian build system's desktop configuration files, such as config/desktop/trixie/environments/gnome/armbian/create_desktop_package.sh, rely on environment variables like $SRC and $destination that are expected to be set externally before the script is executed.
extensions/ti-debpkgs.sh (11)
Learnt from: leggewie
PR: #8133
File: extensions/apa.sh:1-2
Timestamp: 2025-04-28T08:27:26.890Z
Learning: In the Armbian build system, extension scripts in the extensions/
directory contain hook functions and are meant to be sourced, not executed directly. These scripts don't require a shebang or set -euo pipefail
.
Learnt from: EvilOlaf
PR: #8298
File: extensions/https_proxy.sh:1-9
Timestamp: 2025-06-14T05:53:10.627Z
Learning: In Armbian build framework, extensions are loaded and executed via lib/functions/general/extensions.sh using call_extension_method. The framework sets set -o errexit and set -o errtrace globally, and individual commands run with pipefail protection through the command execution functions.
Learnt from: Grippy98
PR: #8202
File: config/desktop/trixie/environments/gnome/armbian/create_desktop_package.sh:2-3
Timestamp: 2025-05-16T15:34:34.672Z
Learning: The shell scripts in the Armbian build system's desktop configuration files, such as config/desktop/trixie/environments/gnome/armbian/create_desktop_package.sh, rely on environment variables like $SRC and $destination that are expected to be set externally before the script is executed.
Learnt from: EvilOlaf
PR: #8298
File: extensions/https_proxy.sh:1-9
Timestamp: 2025-06-14T05:53:10.627Z
Learning: Armbian build framework extensions are NOT designed to run standalone but are called by the supervisor. The framework provides environment variables like USERPATCHES_PATH and SDCARD, and commands are executed with protection via run_host_command_logged and chroot_sdcard functions that use bash -e -o pipefail.
Learnt from: djurny
PR: #8315
File: lib/functions/rootfs/distro-agnostic.sh:54-68
Timestamp: 2025-06-22T00:45:26.182Z
Learning: In Armbian build system, external command dependencies like envsubst are handled by adding the required packages (e.g., gettext for envsubst) to host_dependencies in adaptative_prepare_host_dependencies function in lib/functions/host/prepare-host.sh, rather than checking command availability at runtime.
Learnt from: EvilOlaf
PR: #8417
File: config/boards/orangepi5pro.csc:57-58
Timestamp: 2025-07-23T07:30:52.265Z
Learning: In the Armbian build system, BOOTPATCHDIR can contain board-specific subdirectories (e.g., board_orangepi5pro) for applying patches to specific boards only. The framework automatically checks if such board-specific subdirectories exist for the board being built and applies those patches accordingly.
Learnt from: amazingfate
PR: #8419
File: lib/functions/host/prepare-host.sh:272-275
Timestamp: 2025-07-23T10:01:41.310Z
Learning: In the Armbian build system, the design philosophy is to fail fast when host dependencies are not met rather than gracefully skipping unsupported architectures. This ensures build environment consistency and prevents silent failures. Host dependency checks should be explicit and non-negotiable.
Learnt from: EvilOlaf
PR: armbian/build#0
File: :0-0
Timestamp: 2025-07-21T04:12:02.439Z
Learning: In the Armbian build system, for recurring maintenance tasks like kernel version bumping, TODO comments should use generic version formats (e.g., "MAJOR.MINOR-rc1") rather than specific version numbers (e.g., "6.17-rc1") to avoid the need for frequent comment updates that would create unnecessary maintenance overhead.
Learnt from: djurny
PR: #8287
File: config/bootscripts/boot-sunxi.cmd:148-161
Timestamp: 2025-06-12T21:03:39.686Z
Learning: In Armbian U-Boot bootscripts, the ${cpu}
environment variable is always pre-set by U-Boot (or defaults to a valid value), so additional guards against it being unset are unnecessary.
Learnt from: djurny
PR: #8235
File: packages/bsp/mvebu/helios4/helios4-wol.service:0-0
Timestamp: 2025-05-29T01:52:21.381Z
Learning: In systemd service ExecStart commands, shell variables like ${INTF} can cause issues because systemd may resolve them before the shell processes them, leading to "no device matches name" errors. Using xargs with -I{} is a more reliable approach for iterating over dynamic lists in systemd services, as it avoids variable substitution problems entirely.
Learnt from: pyavitz
PR: #8388
File: config/boards/kickpik2b.conf:1-14
Timestamp: 2025-07-17T04:12:33.125Z
Learning: In the Armbian build system, board configuration files (*.conf) follow a project standard of not including shebang lines, even though they contain bash code and are sourced by the build system. This is an established Armbian convention that individual contributors are expected to follow, and changes to this standard would require broader project maintainer approval.
🧬 Code Graph Analysis (1)
extensions/ti-debpkgs.sh (3)
lib/functions/rootfs/post-tweaks.sh (1)
post_debootstrap_tweaks
(10-34)lib/functions/rootfs/customize.sh (2)
run_hooks_post_armbian_repo_customize_image
(59-66)customize_image
(10-51)extensions/network/net-systemd-networkd.sh (1)
pre_install_kernel_debs__configure_systemd_networkd
(14-42)
extensions/ti-debpkgs.sh
Outdated
function pre_customize_image__enable_services() { | ||
chroot_sdcard "groupadd nopasswdlogin" | ||
chroot_sdcard "useradd -m -s /bin/bash weston" | ||
chroot_sdcard "usermod -aG video,render,input,nopasswdlogin weston" | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🛠️ Refactor suggestion
Make user/group creation idempotent to avoid hard-failures on rebuilds
groupadd
and useradd
abort with non-zero exit codes when the entity already exists.
Because chroot_sdcard
executes with set -e
, a rebuild or a base image that already ships the nopasswdlogin
group (or a weston
user) will terminate the whole build.
- chroot_sdcard "groupadd nopasswdlogin"
- chroot_sdcard "useradd -m -s /bin/bash weston"
+ # Create only if missing – keeps the hook idempotent
+ chroot_sdcard "getent group nopasswdlogin || groupadd --system nopasswdlogin"
+ chroot_sdcard "id -u weston >/dev/null 2>&1 || useradd --system -m -s /bin/bash weston"
Also consider guarding the subsequent usermod
against missing auxiliary groups (input
, render
, …) or create them up-front for the same reason.
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
function pre_customize_image__enable_services() { | |
chroot_sdcard "groupadd nopasswdlogin" | |
chroot_sdcard "useradd -m -s /bin/bash weston" | |
chroot_sdcard "usermod -aG video,render,input,nopasswdlogin weston" | |
function pre_customize_image__enable_services() { | |
# Create only if missing – keeps the hook idempotent | |
chroot_sdcard "getent group nopasswdlogin || groupadd --system nopasswdlogin" | |
chroot_sdcard "id -u weston >/dev/null 2>&1 || useradd --system -m -s /bin/bash weston" | |
chroot_sdcard "usermod -aG video,render,input,nopasswdlogin weston" | |
🤖 Prompt for AI Agents
In extensions/ti-debpkgs.sh around lines 39 to 43, the groupadd and useradd
commands are not idempotent and will fail if the group or user already exists,
causing the build to terminate. Modify the script to first check if the group
'nopasswdlogin' exists before attempting to add it, and similarly check if the
user 'weston' exists before adding. Also, ensure that the auxiliary groups
'video', 'render', 'input', and 'nopasswdlogin' exist before running usermod to
add the user to these groups, creating any missing groups as needed to prevent
failures.
8399056
to
5ed3111
Compare
5ed3111
to
e77bc6e
Compare
if [[ "${GPU_SUPPORT}" == "yes" ]] ; then | ||
TI_PACKAGES+=("ti-img-rogue-driver-${SOC_ID}-dkms" "ti-img-rogue-umlibs-${SOC_ID}" "ti-img-rogue-tools-${SOC_ID}" "ti-img-rogue-firmware-${SOC_ID}") | ||
TI_PACKAGES+=("mesa-vulkan-drivers" "libgl1-mesa-dri") | ||
TI_PACKAGES+=("gstreamer1.0-tools" "gstreamer1.0-plugins-good" "gstreamer1.0-plugins-bad" "gstreamer1.0-plugins-base") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What uses these? Shouldn't the user pull these in if they need them like other packages?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My rationale is: our boards are for evaluating and prototyping with our SoCs. If our SoC supports camera, then our image should ideally have by-default whatever it needs to run the camera. Our docs run the camera with GStreamer, which is why I added these. We had these in our previous flavour of Debian as well.
fi | ||
|
||
if [[ "${CHROMIUM_SUPPORT}" == "yes" ]] ; then | ||
TI_PACKAGES+=("chromium") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same for this, shouldn't this be installed by the user if they want it? Customization for our default images like this should probably start going into APA.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My rationale is: our boards are for evaluating and prototyping with our SoCs. If our SoC supports camera, then our image should ideally have by-default whatever it needs to run the camera. Our docs run the camera with GStreamer, which is why I added these. We had these in our previous flavour of Debian as well.
Same answer, but adapted to showing off GPU acceleration with browser. We had this in previous Debian, and also have it as a demo in our docs.
But I can remove both GStreamer and Chromium, if you disagree with this
Default and officially supported TI images will be the console image with emptty (display manager) running weston on top of it. Therefore add weston and emptty in the list of packages to install. Also, for emptty, change the conffile `/etc/pam.d/emptty`. Debian allows editing these files [0]. Further, add an explicit step to bind dkms packages to kernel. Currently the dkms package gets installed before the kernel, therefore if this step is excluded, the binding would occur on first boot, which would cause the first boot time to get longer. Therefore add the "dkms autoinstall" step. Additionally, add firmware, gstreamer, chromium etc packages. [0] https://www.debian.org/doc/manuals/maint-guide/dother.en.html#conffiles Signed-off-by: Suhaas Joshi <[email protected]>
`vim` is pretty widely used, so include it in the list of default packages to install in a CLI image. Signed-off-by: Suhaas Joshi <[email protected]>
e77bc6e
to
98734f1
Compare
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 Debian images support different features, such as IPC, Weston (as OOB screen), GPU acceleration, camera etc. So to have these working by-default in our images, this PR adds certain packages such as:
Additionally, there are 2 more things done here:
/lib/systemd/system/
. This is to start weston on boot by-default. Note that weston doesn't launch on first boot when the armbian-firstlogin script runs, but starts launching from subsequent boots.dkms autoinstall
builds and installs the ti-img-rogue--dkms package for the current kernel. If this isn't done here, it will done during first boot, which would make the first boot very slow.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.
Checklist:
Please delete options that are not relevant.