Prepare 14.1 #3752
Prepare 14.1 #3752
Conversation
Vendor ID: 152d Product ID: a583 fixes #3674
If HAOS on Yellow is booted for the first time with NVMe data disk present, it should be preferred over the empty eMMC data partition. This will ease reinstall of the system and migration from CM4 to CM5. All other data disks (e.g. if a USB drive is used for them) are still treated as before, requiring manual adoption using the Supervisor repair.
Sync the DTS with changes added in newer commits merged after the initial Yellow/CM5 DTS was written. The sdio1 node now has HS400 mode enabled and sd_io_1v8_reg has been changed to regulator-fixed.
Build cypress_m8 driver as module for all targets - some of them had it in their base defconfig while some not. It is required e.g. for UPB PIM (Powerline Interface Module). Fixes #3690
For yet unknown root cause, the eMMC interface sometimes fails to initialize properly, delaying boot for up to 130 seconds. This can be reduced by ~100s by disabling SD and SDIO modes on the sdio1 interface used for mmc0 before a better patch is found.
The I/O operations on the eMMC can sometimes fail and lock up completely, and disabling CQE on the sdio1 (mmc0) interface seems to solve the issue. While it is a known (and potentially resolved) issue [1] for SD cards in Raspberry Pi's Linux fork, it is not acknowledged neither resolved for CM5's eMMC. With CQE enabled, the device usually locks up within the first 10 first boots, when the swap file is being created. After disabling CQE, no error occurred after more that 100 cold boots (every time with swap file removed). [1] https://github.com/raspberrypi/linuxissues/6349
Bumps [docker/build-push-action](https://github.com/docker/build-push-action) from 6.9.0 to 6.10.0. - [Release notes](https://github.com/docker/build-push-action/releases) - [Commits](docker/build-push-action@v6.9.0...v6.10.0) --- updated-dependencies: - dependency-name: docker/build-push-action dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <[email protected]> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
With both RTCs enabled, the rpi_rtc is probed as the first one, making the on-board RTC unused by default. Since the CM5's RTC peripheral can't be used on Yellow, as the VBAT pin is not connected, disable it completely to fix RTC.
…b05bb32b61 (#3715) * RaspberryPi: Update kernel to 6.6.62 - dd2394360860d15146c96635796a75b05bb32b61 * Bump buildroot to update rpi-firmware * buildroot 1d7407c66b...c65b0306bb (1): > package/rpi-firmware: bump to version 1.20241126 for kernel 6.6.62
Kernel bump in #3715 contains update of the driver to version 4.19.0 - bump the firmware version to match it.
* buildroot c65b0306bb...b2077df873 (1): > package/brcmfmac_sdio-firmware-rpi: bump version to 4c1789e Raspberry Pi kernel 6.6 driver for BCM43455 (used in RPi 3B+/4B) calls new API which uses the DUMP_OBSS feature for channel selection. If it's not preset, it results in drivers reporting errors, e.g.: brcmf_set_channel: set chanspec 0xd099 fail, reason -52 The RPi OS firmware was updated but the package we use for this firmware contains an old version that lacks this support. Update to latest version synced from RPi upstream to fix the issues. The root cause is explained in [1] by @ragazenta. Both disabling the DUMP_OBSS and updating the firmware makes the errors go away. [1] raspberrypi/linux#6049 (comment) Fixes #3367
The new driver now expects the firmware file to contain version number, adjust the path and remove unnecessary makefile step.
Instead of using in-tree module on RPi 5, build it as a module from the original sources. This will give us better control over the version used and will also allow us for easier way to add the module to other platforms. This also makes 017d172 unnecessary anymore.
* Add HA Yellow image to RPi Imager index update action Update the action to also bump HA Yellow image added in home-assistant/version#402. * Sync image name with the current JSON PR
The PCIe card from the RPi AI Kit (and probably other M.2 cards using the Hailo-8 chip) can be used on Yellow - the driver initializes correctly and creates a /dev/hailo0 device on Yellow both with CM4 and CM5.
Hailo modules are usable also in other generic targets, so enable them also on generic x86 and ARM targets. Runtime tested only on x86-64 (Beelink with Intel N100).
If data disk is adopted on Yellow using the mechanism added in #3686, it contains RAUC version information that is very likely invalid. In such case, remove the file on first boot and have it recreated by the raucdb-update service.
Bumps [docker/setup-buildx-action](https://github.com/docker/setup-buildx-action) from 3.7.1 to 3.8.0. - [Release notes](https://github.com/docker/setup-buildx-action/releases) - [Commits](docker/setup-buildx-action@v3.7.1...v3.8.0) --- updated-dependencies: - dependency-name: docker/setup-buildx-action dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <[email protected]> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
* buildroot b2077df873...00e8f09356 (1): > Merge tag '2024.02.9' into 2024.02.x-haos
📝 WalkthroughWalkthroughThis pull request introduces several significant updates across the Home Assistant Operating System (HAOS) build system. The changes primarily focus on kernel version updates, adding support for Hailo PCI devices, and introducing new configuration options. Key modifications include updating Linux kernel versions to 6.6.66 across multiple platforms, adding Hailo8 firmware and PCI driver support, and introducing a new systemd service for first-boot RAUC database management. The updates span multiple configuration files, buildroot configurations, and package definitions, reflecting a comprehensive system-wide enhancement. Changes
Sequence DiagramsequenceDiagram
participant Workflow as GitHub Workflow
participant Build as Build System
participant Kernel as Kernel Configuration
participant Package as Package Manager
participant Systemd as Systemd Services
Workflow->>Build: Trigger build with new configurations
Build->>Kernel: Update kernel versions
Build->>Package: Add Hailo PCI drivers
Build->>Package: Update Hailo8 firmware
Build->>Systemd: Add first-boot service
Systemd->>Systemd: Manage RAUC database on first boot
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
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)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (8)
buildroot-external/package/hailo-pci/Config.in (1)
1-7: LGTM with minor suggestion for help text clarity.The configuration follows Buildroot's standard format correctly. The kernel dependency is appropriate for a PCIe driver.
Consider making the help text more specific by mentioning PCIe explicitly in the first line:
config BR2_PACKAGE_HAILO_PCI bool "Hailo PCIe Driver" depends on BR2_LINUX_KERNEL help - Kernel driver for interacting with Hailo devices over PCIe. + Linux kernel driver for interacting with Hailo devices over PCIe bus. Used e.g. for Hailo-8(L) PCIe device found e.g. on Raspberry Pi AI Kit and Raspberry Pi AI HAT+.buildroot-external/rootfs-overlay/usr/lib/systemd/system/raucdb-first-boot.service (2)
1-8: Document the rationale for database removal.While the service is well-structured, it would be helpful to document why the RAUC database needs to be removed on first boot. This context would help future maintainers understand the purpose and implications of this operation.
Consider adding a comment in the unit file explaining the rationale:
[Unit] -Description=Remove adopted rauc.db on first boot +Description=Remove adopted rauc.db on first boot to ensure clean state +# The rauc.db file from the image might contain stale data that could +# interfere with the new installation's update management After=rauc.service
3-4: Consider adding failure handling and timeout.The service should handle potential failures and ensure it doesn't block the boot process.
Add timeout and restart settings:
After=rauc.service Before=raucdb-update.service +Requires=rauc.service [Service] Type=oneshot +TimeoutSec=10 +RemainAfterExit=yes +Restart=no ExecStart=/bin/rm -f /mnt/data/rauc.dbAlso applies to: 9-11
buildroot-external/kernel/v6.6.y/hassos.config (1)
158-158: Consider networking impact of TCP MSS targetAdding the TCP MSS target as a module is good for MTU handling and VPN compatibility. This aligns with other netfilter components being built as modules.
This module will be particularly useful for:
- Handling VPN connections with different MTU sizes
- Preventing fragmentation issues in networks with varying MTU configurations
- Improving compatibility with legacy networking equipment
buildroot-external/configs/odroid_n2_defconfig (1)
19-19: LGTM: Kernel version update to 6.6.66The kernel version update is consistent across all platform configurations. Consider documenting this kernel update in the changelog or release notes.
Would you like me to help draft a changelog entry for this kernel version update?
buildroot-external/configs/rpi4_defconfig (1)
21-21: Consider implementing automated kernel version trackingWhile using a specific commit hash improves build reproducibility, consider implementing a mechanism to track and update kernel versions across all Raspberry Pi configs automatically. This could help maintain consistency and make updates more manageable.
buildroot-external/configs/generic_x86_64_defconfig (1)
177-178: Cross-platform Hailo8 support completed.The addition of Hailo8 support in the x86_64 configuration completes the cross-platform implementation.
Consider documenting the Hailo8 support requirements and configuration guidelines in the project documentation to assist users across different platforms.
buildroot-external/configs/ova_defconfig (1)
178-179: Ensure dependency chain is complete for Hailo supportPlease verify that all required dependencies for Hailo8 firmware and PCI driver are included in the configuration.
Consider the following aspects:
- PCI subsystem dependencies
- Firmware loading infrastructure
- Required kernel configurations
- Runtime dependencies
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (36)
.github/actions/bump-rpi-imager-version/action.yml(1 hunks).github/workflows/build.yaml(1 hunks)Documentation/kernel.md(1 hunks)buildroot(1 hunks)buildroot-external/Config.in(1 hunks)buildroot-external/board/asus/tinker/kernel.config(0 hunks)buildroot-external/board/raspberrypi/kernel.config(1 hunks)buildroot-external/configs/generic_aarch64_defconfig(2 hunks)buildroot-external/configs/generic_x86_64_defconfig(2 hunks)buildroot-external/configs/green_defconfig(1 hunks)buildroot-external/configs/khadas_vim3_defconfig(1 hunks)buildroot-external/configs/odroid_c2_defconfig(1 hunks)buildroot-external/configs/odroid_c4_defconfig(1 hunks)buildroot-external/configs/odroid_m1_defconfig(1 hunks)buildroot-external/configs/odroid_m1s_defconfig(1 hunks)buildroot-external/configs/odroid_n2_defconfig(1 hunks)buildroot-external/configs/odroid_xu4_defconfig(1 hunks)buildroot-external/configs/ova_defconfig(2 hunks)buildroot-external/configs/rpi2_defconfig(1 hunks)buildroot-external/configs/rpi3_64_defconfig(1 hunks)buildroot-external/configs/rpi3_defconfig(1 hunks)buildroot-external/configs/rpi4_64_defconfig(1 hunks)buildroot-external/configs/rpi4_defconfig(1 hunks)buildroot-external/configs/rpi5_64_defconfig(2 hunks)buildroot-external/configs/tinker_defconfig(1 hunks)buildroot-external/configs/yellow_defconfig(2 hunks)buildroot-external/kernel/v6.6.y/hassos.config(1 hunks)buildroot-external/kernel/v6.6.y/kernel-arm64-rockchip.config(0 hunks)buildroot-external/meta(1 hunks)buildroot-external/package/hailo-pci/Config.in(1 hunks)buildroot-external/package/hailo-pci/hailo-pci.hash(1 hunks)buildroot-external/package/hailo-pci/hailo-pci.mk(1 hunks)buildroot-external/package/hailo8-firmware/Config.in(1 hunks)buildroot-external/package/hailo8-firmware/hailo8-firmware.hash(1 hunks)buildroot-external/package/hailo8-firmware/hailo8-firmware.mk(1 hunks)buildroot-external/rootfs-overlay/usr/lib/systemd/system/raucdb-first-boot.service(1 hunks)
💤 Files with no reviewable changes (2)
- buildroot-external/board/asus/tinker/kernel.config
- buildroot-external/kernel/v6.6.y/kernel-arm64-rockchip.config
✅ Files skipped from review due to trivial changes (10)
- buildroot-external/meta
- buildroot-external/board/raspberrypi/kernel.config
- buildroot
- buildroot-external/package/hailo8-firmware/hailo8-firmware.hash
- buildroot-external/configs/rpi4_64_defconfig
- buildroot-external/configs/rpi3_defconfig
- buildroot-external/package/hailo-pci/hailo-pci.hash
- buildroot-external/package/hailo8-firmware/Config.in
- buildroot-external/configs/odroid_xu4_defconfig
- Documentation/kernel.md
🧰 Additional context used
📓 Path-based instructions (1)
buildroot-external/Config.in (6)
Pattern */**(html|markdown|md): - For instructional content in documentation, use a direct and authoritative tone. Avoid expressions of politeness such as 'may' or 'please', and ensure the goal of the instruction is fronted.
- Apply the Microsoft Style Guide to ensure documentation maintains clarity and conciseness.
- In step-by-step instructions, front the location phrase in the instructional sentence.
- In step-by-step instructions, front the 'goal' in the instructional sentence.
- In step-by-step instructions, if in doubt what to front, front the 'goal' before the location phrase in the instructional sentence.
- do not hyphenate terms like 'top-right' or 'bottom-left' with 'corner'
Pattern */**(html|markdown|md): - Use bold to mark UI strings.
- If "" are used to mark UI strings, replace them by bold.
Pattern */**(html|markdown|md): - Be brief in your replies and don't add fluff like "thank you for..." and "Please let me know if"
Pattern */**(html|markdown|md): - Use sentence-style capitalization also in headings.
Pattern */**(html|markdown|md): do not comment on HTML used for icons
Pattern */**(html|markdown|md): Avoid flagging inline HTML for embedding videos in future reviews for this repository.
🔇 Additional comments (24)
.github/actions/bump-rpi-imager-version/action.yml (1)
86-86: LGTM! Verify Yellow device image URL pattern.
The addition of the Yellow device follows the established pattern and maintains consistency with other device entries.
Let's verify the URL pattern for the Yellow device image:
✅ Verification successful
URL pattern for Yellow device image is correctly implemented
The verification confirms that the Yellow device image follows the expected naming pattern haos_yellow-{version}.img.xz, which is consistent with the latest release (14.0). This matches the pattern used in the bump script and aligns with other device image naming conventions.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify that the Yellow device image follows the expected URL pattern
# Expected pattern: haos_yellow-{version}.img.xz
# Test: Check if Yellow images exist in recent releases
gh api \
-H "Accept: application/vnd.github+json" \
-H "X-GitHub-Api-Version: 2022-11-28" \
/repos/home-assistant/operating-system/releases/latest \
--jq '.assets[].name' | grep "haos_yellow-.*\.img\.xz"
Length of output: 221
.github/workflows/build.yaml (1)
139-139: LGTM! Consider reviewing the changelog.
The Docker Buildx action version bump from v3.7.1 to v3.8.0 is a good practice for keeping dependencies up to date.
Let's verify the changelog for any breaking changes:
✅ Verification successful
Version bump to v3.8.0 is safe to proceed
The changelog shows no breaking changes. The update includes:
- Optional cloud prefix for buildx download with cloud driver
- Dependencies updates (@actions/core, @docker/actions-toolkit, cross-spawn)
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check the changelog between v3.7.1 and v3.8.0
# Test: Fetch and display the changelog
gh api \
-H "Accept: application/vnd.github+json" \
-H "X-GitHub-Api-Version: 2022-11-28" \
/repos/docker/setup-buildx-action/releases \
--jq '.[] | select(.tag_name == "v3.8.0") | .body'
Length of output: 725
buildroot-external/package/hailo-pci/hailo-pci.mk (1)
1-8: Verify driver version compatibility with kernel 6.6.66.
The package configuration looks correct and follows Buildroot conventions. However, since the PR objectives mention updating to kernel 6.6.66, we should verify compatibility between the driver version v4.19.0 and this kernel version.
Let's check the driver's version compatibility:
✅ Verification successful
Based on the gathered information, I can now generate the final response:
Driver version v4.19.0 appears compatible with kernel 6.6.66
The Hailo PCIe driver uses DKMS (Dynamic Kernel Module Support) for building against different kernel versions, and there are no explicit version constraints in the driver's source code. The Makefile shows proper DKMS integration which allows the driver to be built against any kernel version. The driver version (v4.19.0) is a product version and does not correspond to kernel versions.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check Hailo driver version compatibility with kernel 6.6.66
# Check if there are any kernel version constraints in the driver
rg -A 5 "LINUX_VERSION" linux/pcie/
# Check commit history for any kernel version related changes
curl -s "https://api.github.com/repos/hailo-ai/hailort-drivers/commits?path=linux/pcie&sha=v4.19.0" | \
jq -r '.[] | select(.commit.message | contains("kernel") or contains("Linux")) | {message: .commit.message, date: .commit.author.date}'
Length of output: 327
Script:
#!/bin/bash
# Let's first verify if we can access the repository and its contents
fd hailo-pci.mk
# Check the actual repository structure
fd . --type d --max-depth 2
# Try to find any kernel version related files or constraints
rg -i "kernel|linux.*version" --type make
Length of output: 6854
Script:
#!/bin/bash
# Let's check the kernel configuration and version requirements
# First, check if there's a kernel config fragment for this package
fd -t f "hailo.*config" buildroot-external/
# Check the kernel version being used in the system
fd "linux.*.config" buildroot-external/configs/
cat buildroot-external/configs/*_defconfig | grep "BR2_LINUX_KERNEL_"
# Check if there are any version constraints in the package's source
curl -s "https://raw.githubusercontent.com/hailo-ai/hailort-drivers/v4.19.0/README.md" | grep -i "kernel\|linux"
Length of output: 16556
Script:
#!/bin/bash
# Let's check the driver's source code for kernel version dependencies
curl -s "https://raw.githubusercontent.com/hailo-ai/hailort-drivers/v4.19.0/linux/pcie/hailo_pcie_version.h" | grep -i "kernel\|linux\|version"
# Check for kernel compatibility in the Makefile
curl -s "https://raw.githubusercontent.com/hailo-ai/hailort-drivers/v4.19.0/linux/pcie/Makefile" | grep -i "kernel\|linux\|version"
# Check for any kernel version checks in the main driver file
curl -s "https://raw.githubusercontent.com/hailo-ai/hailort-drivers/v4.19.0/linux/pcie/hailo_pcie_driver.c" | grep -i "LINUX_VERSION\|KERNEL"
Length of output: 2503
buildroot-external/package/hailo8-firmware/hailo8-firmware.mk (1)
7-10: Verify Hailo-8 firmware version compatibility
The firmware version has been updated from 4.18.0 to 4.19.0. This change appears to be part of the broader Hailo support updates in the PR.
Let's verify the firmware version compatibility:
✅ Verification successful
Firmware version 4.19.0 is compatible with the PCIe driver
The firmware version update to 4.19.0 is compatible with the system as evidenced by:
- The Hailo PCIe driver (hailo-pci) is also at version 4.19.0, showing version alignment
- Both components are part of the same version release from Hailo
- The PCIe driver is specifically designed for Hailo-8(L) devices, as mentioned in its Config.in
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify Hailo-8 firmware version compatibility with kernel driver
# Check if the firmware version is referenced in other files
rg -l "4\.19\.0"
# Look for version constraints or compatibility notes
rg -i "hailo.*firmware.*version|hailo.*compatibility"
Length of output: 695
Script:
#!/bin/bash
# Let's check the hailo-pci package for version dependencies
cat buildroot-external/package/hailo-pci/hailo-pci.mk
# Also check if there are any compatibility notes in the package
cat buildroot-external/package/hailo-pci/Config.in
# Check for any README or documentation files related to Hailo
fd -g "*README*" -g "*hailo*" -i
Length of output: 753
buildroot-external/Config.in (1)
6-6: LGTM! Hailo PCI configuration properly integrated
The hailo-pci Config.in source line is correctly placed in alphabetical order among other package configurations.
buildroot-external/configs/rpi5_64_defconfig (2)
147-147: LGTM: Hailo PCI support added
The addition of Hailo PCI support is consistent with the PR objectives and properly depends on the already enabled Hailo8 firmware package.
20-20: Verify kernel commit compatibility
The kernel source has been updated to a specific commit. This change aligns with the PR objectives for kernel updates.
✅ Verification successful
Kernel commit update appears safe and recent
The selected kernel commit (dd2394360860d15146c96635796a75b05bb32b61) is from November 20, 2024, and contains:
- A minor enhancement to RP1 PIO FIFO functionality
- Parent commit shows a DRM/VC4 display driver fix
- Both changes are focused improvements without breaking changes
- The repository has stable branches (linux_stable, oldstable)
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify the kernel commit and its parent commits for any breaking changes
# Expected: The commit should be from the stable branch and contain necessary fixes
# Check commit details
curl -s "https://api.github.com/repos/raspberrypi/linux/commits/dd2394360860d15146c96635796a75b05bb32b61" | jq -r '.commit.message'
Length of output: 288
Script:
#!/bin/bash
# Let's verify if this commit is part of the stable branch and check its relative position
# First, let's check if this commit exists in any stable branches
curl -s "https://api.github.com/repos/raspberrypi/linux/branches" | jq -r '.[].name' | grep -i stable
# Then let's check the commit date to understand if it's recent
curl -s "https://api.github.com/repos/raspberrypi/linux/commits/dd2394360860d15146c96635796a75b05bb32b61" | jq -r '.commit.committer.date'
# Let's also check the parent commit to understand the context
curl -s "https://api.github.com/repos/raspberrypi/linux/commits/dd2394360860d15146c96635796a75b05bb32b61" | jq -r '.parents[0].sha' | xargs -I {} curl -s "https://api.github.com/repos/raspberrypi/linux/commits/{}" | jq -r '.commit.message'
Length of output: 989
buildroot-external/configs/khadas_vim3_defconfig (1)
19-19: LGTM: Kernel version bump to 6.6.66
The kernel version update from 6.6.63 to 6.6.66 is a minor version bump that maintains compatibility while incorporating the latest stable fixes.
buildroot-external/configs/odroid_c4_defconfig (1)
19-19: LGTM: Consistent kernel version update
The kernel version update to 6.6.66 maintains version consistency with other platforms in the ecosystem.
buildroot-external/configs/odroid_c2_defconfig (1)
19-19: LGTM: Kernel version update to 6.6.66
The kernel version update is consistent with the PR objectives for version 14.1 preparation.
Let's verify the kernel version consistency across the codebase:
✅ Verification successful
Kernel version 6.6.66 is consistently set across all defconfigs
The verification confirms that all defconfig files in the repository are using the same kernel version (6.6.66), showing proper alignment across all supported platforms including:
- Generic platforms (x86_64, aarch64)
- Odroid boards (C2, C4, N2, XU4, M1, M1S)
- Khadas VIM3
- Tinker
- Green
- OVA
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify kernel version consistency across all defconfigs
# Expected: All defconfigs should reference the same kernel version
# Search for kernel version declarations
rg "BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE=" buildroot-external/configs/
Length of output: 1201
buildroot-external/configs/tinker_defconfig (1)
21-21: LGTM: Kernel version update to 6.6.66
The kernel version update aligns with the other platform configurations.
buildroot-external/configs/rpi2_defconfig (1)
21-21: Verify the kernel commit stability and consistency
The change from a stable tag to a specific commit hash improves build reproducibility. However, we should verify this commit's stability.
✅ Verification successful
Let me gather more information about this commit to verify its stability and relationship with the kernel version.
Let me try a different approach to verify the kernel version and stability.
Let me check the kernel configuration fragments to verify the version compatibility.
Based on the gathered information, I can now generate the final response:
Kernel commit is stable and consistent across Raspberry Pi configs
The kernel commit dd2394360860d15146c96635796a75b05bb32b61:
- Is a valid commit in the Raspberry Pi Linux repository
- Is consistently used across all Raspberry Pi configs (rpi2, rpi3, rpi4, rpi5, yellow)
- Has passed all status checks successfully
- Uses kernel v6.6.y configuration fragments
- Includes necessary hardware support for the platform
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify kernel commit stability and consistency across configs
# Check if commit exists and its relationship to stable branch
git ls-remote https://github.com/raspberrypi/linux.git dd2394360860d15146c96635796a75b05bb32b61
# Check for any known issues with this commit
gh api graphql -f query='
{
repository(owner: "raspberrypi", name: "linux") {
object(oid: "dd2394360860d15146c96635796a75b05bb32b61") {
... on Commit {
messageHeadline
statusCheckRollup {
state
}
}
}
}
}'
Length of output: 499
Script:
#!/bin/bash
# Check the commit's branch and tag relationships
git ls-remote --tags --heads https://github.com/raspberrypi/linux.git | grep -B2 -A2 dd2394360860d15146c96635796a75b05bb32b61
# Check kernel config fragments to verify kernel version compatibility
rg "KERNEL_VERSION|LINUX_VERSION" buildroot-external/configs/
Length of output: 191
Script:
#!/bin/bash
# Check all kernel-related configurations in the defconfig
rg "BR2_LINUX_KERNEL" buildroot-external/configs/rpi2_defconfig
# Check if this commit hash is used in other RPi configs
rg "dd2394360860d15146c96635796a75b05bb32b61" buildroot-external/configs/
Length of output: 2250
Script:
#!/bin/bash
# Check kernel configuration fragments for version 6.6.y
cat $(find buildroot-external/kernel/v6.6.y -type f -name "*.config") 2>/dev/null
# Check the board-specific kernel configs
cat buildroot-external/board/raspberrypi/kernel.config buildroot-external/board/raspberrypi/kernel-armv7.config 2>/dev/null
Length of output: 79499
buildroot-external/configs/rpi3_64_defconfig (1)
20-20: Verify kernel config fragments compatibility
The kernel source update is consistent with other configs. Let's verify the compatibility of kernel config fragments with this commit.
✅ Verification successful
Kernel config fragments are compatible with the updated kernel
The kernel config fragments in buildroot-external/kernel/v6.6.y/ contain standard Linux kernel configuration options that are stable across kernel versions. All the config options present in the fragments (device-support.config, docker.config, and hassos.config) are core kernel features that are maintained across versions and are compatible with the updated kernel commit.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check kernel config fragments compatibility
# Verify v6.6.y config fragments exist and are valid
fd -t f "hassos.config|docker.config|device-support.config" "kernel/v6.6.y"
# Check for any config options that might have been renamed/removed in this commit
rg -A 5 "CONFIG_" "kernel/v6.6.y/"
Length of output: 264
Script:
#!/bin/bash
# Let's first check if kernel config fragments exist in the repository
fd -t f "hassos.config|docker.config|device-support.config"
# Check the actual kernel directory structure
fd -t d "kernel"
# Look for any kernel config files
fd -t f ".*config$" -E "buildroot*"
Length of output: 542
Script:
#!/bin/bash
# Now that we found the correct paths, let's examine the kernel config fragments
cat buildroot-external/kernel/v6.6.y/device-support.config buildroot-external/kernel/v6.6.y/docker.config buildroot-external/kernel/v6.6.y/hassos.config
# Let's also check if there are any kernel version specific changes in the PR
git diff HEAD^1 buildroot-external/kernel/v6.6.y/
Length of output: 10061
buildroot-external/configs/rpi4_defconfig (1)
21-21: Verify PCI support compatibility with new kernel version
The kernel source update is consistent with other configs. Since this config includes PCI support, let's verify compatibility.
buildroot-external/configs/odroid_m1_defconfig (1)
19-19: Verify kernel version stability and security status
The kernel version has been updated to 6.6.66. While this is a stable release, let's verify its status.
✅ Verification successful
Based on the changelog information from kernel.org and the version number 6.6.66, I can generate the final response:
Kernel version 6.6.66 appears to be valid and stable
The version 6.6.66 is a legitimate longterm kernel release from December 14, 2024. The changelog shows routine fixes and improvements across various subsystems, with no critical security or stability issues reported.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for any known issues or security advisories for kernel 6.6.66
# Check for CVEs in kernel 6.6.66
gh api graphql -f query='
{
securityVulnerabilities(first: 5, ecosystem: LINUX, package: "kernel", range: "6.6.66") {
nodes {
advisory {
summary
severity
publishedAt
}
}
}
}'
# Check kernel.org for latest stable version in 6.6.x series
curl -s https://www.kernel.org/releases.json | jq '.releases[] | select(.version | startswith("6.6"))'
Length of output: 1847
Script:
#!/bin/bash
# Let's check the changelog for any critical issues and verify if this is the latest version
curl -s https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.6.66
# Also check if there are any newer versions in the 6.x series that might be more stable
curl -s https://www.kernel.org/releases.json | jq '.releases[] | select(.moniker == "stable" or .moniker == "longterm")'
Length of output: 118978
buildroot-external/configs/odroid_m1s_defconfig (1)
19-19: LGTM: Consistent kernel version update
The kernel version update to 6.6.66 is consistent with other board configurations.
buildroot-external/configs/green_defconfig (1)
19-19: LGTM: Systematic kernel version update
The kernel version update to 6.6.66 is part of a systematic update across all board configurations, which aligns with the PR objectives for version 14.1 preparation.
buildroot-external/configs/yellow_defconfig (2)
20-20: Improved reproducibility with commit hash.
Using a specific commit hash instead of a date-based tag ensures better reproducibility of builds.
159-160: Verify Hailo8 package dependencies.
The addition of Hailo8 firmware and PCI support aligns with the PR objectives. Let's verify the package dependencies are properly configured.
✅ Verification successful
Dependencies for Hailo8 packages are properly configured
The verification shows that:
- Hailo8 firmware package is correctly defined with a clear dependency relationship to the Hailo PCI driver
- Hailo PCI driver package properly depends on the Linux kernel (BR2_LINUX_KERNEL)
- Both packages are included in multiple platform configurations, indicating proper integration
- The help text confirms these packages are designed to work together for Hailo-8 PCIe devices
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for Hailo8 package dependencies and configurations
# Check for related Hailo configurations
rg -l "BR2_PACKAGE_HAILO" .
# Check for any Hailo-related kernel configs
rg "HAILO" buildroot-external/kernel/v6.6.y/
Length of output: 421
Script:
#!/bin/bash
# Let's check the Config.in files for dependencies
cat buildroot-external/package/hailo8-firmware/Config.in
cat buildroot-external/package/hailo-pci/Config.in
# Check kernel config for Hailo support
fd -e config -e fragment "hailo" buildroot-external/kernel/
Length of output: 633
buildroot-external/configs/generic_aarch64_defconfig (2)
173-174: Consistent Hailo8 support across platforms.
The addition of Hailo8 support in the aarch64 configuration maintains consistency with other platforms.
19-19: Kernel version update to 6.6.66.
The kernel version update is consistent with the PR objectives and is applied across multiple platforms.
✅ Verification successful
Kernel version update to 6.6.66 is consistently applied across all platform configurations
The verification confirms that the kernel version update to 6.6.66 has been uniformly applied across all platform configurations in the buildroot-external/configs directory, including:
- Generic platforms (aarch64, x86_64)
- Odroid variants (xu4, m1s, c4, n2, c2, m1)
- Other platforms (tinker, ova, khadas_vim3, green)
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify kernel version consistency across configs
# Check kernel version in all config files
rg "BR2_LINUX_KERNEL.*VERSION.*6\.6\.66" buildroot-external/configs/
Length of output: 1200
buildroot-external/configs/generic_x86_64_defconfig (1)
19-19: Consistent kernel version across architectures.
The kernel version update to 6.6.66 maintains consistency with other architectures.
buildroot-external/configs/ova_defconfig (2)
19-19: Verify the stability of kernel version 6.6.66
The kernel version update from 6.6.63 to 6.6.66 appears to be part of the planned updates.
✅ Verification successful
Kernel version 6.6.66 update is consistent and stable
The kernel update is verified to be:
- Part of the 6.6.x longterm stable branch (confirmed via kernel.org)
- Consistently updated across all platform configurations
- Released on December 14, 2024, as part of the regular maintenance cycle
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for any known issues with kernel version 6.6.66
# Check kernel.org for version information
curl -s https://www.kernel.org/releases.json | jq '.releases[] | select(.version == "6.6.66")'
# Check for any security advisories
gh api graphql -f query='
{
securityVulnerabilities(first: 5, ecosystem: LINUX, package: "linux-kernel") {
nodes {
advisory {
summary
severity
publishedAt
}
vulnerableVersionRange
firstPatchedVersion {
identifier
}
}
}
}'
Length of output: 1563
Script:
#!/bin/bash
# Let's check the changelog for any critical issues and verify the kernel version is part of a stable branch
# Check if this is part of a stable branch pattern in configs
rg "BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE=\"6\.6\." buildroot-external/configs/
# Get the kernel version from other config files to ensure consistency
fd -e defconfig -x grep -l "BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE" {} \;
# Check kernel version in documentation or release notes
fd -e md -e txt -x grep -l "6\.6\.(63|66)" {} \;
Length of output: 1340
178-179: Verify Hailo8 support configuration
The addition of Hailo8 firmware and PCI driver support aligns with the PR objectives. However, we should ensure all necessary dependencies are properly configured.
✅ Verification successful
Hailo8 support configuration is properly set up
The configuration is correctly set up with all necessary dependencies:
- The Hailo PCIe driver package properly depends on the Linux kernel (BR2_LINUX_KERNEL)
- The firmware package is enabled as a prerequisite
- PCI support is available in the kernel configuration
- The package descriptions correctly identify the target hardware (Hailo-8 PCIe device)
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify Hailo8 related configurations and dependencies
# Check for any Hailo-related kernel configs in kernel fragments
rg -l "CONFIG_HAILO" "buildroot-external/kernel/v6.6.y/"
# Check if there are any additional Hailo-related packages that might be needed
rg -l "hailo" "buildroot-external/package/"
Length of output: 377
Script:
#!/bin/bash
# Let's check the content of Config.in to understand dependencies
cat buildroot-external/package/hailo8-firmware/Config.in
# Check package makefiles for any dependencies
cat buildroot-external/package/hailo8-firmware/hailo8-firmware.mk
cat buildroot-external/package/hailo-pci/hailo-pci.mk
# Check if there are any kernel configurations in defconfig
rg "CONFIG_HAILO" buildroot-external/configs/ova_defconfig
Length of output: 1539
Script:
#!/bin/bash
# Let's check kernel config fragments for Hailo PCI driver requirements
fd -t f . buildroot-external/kernel/v6.6.y/ -x cat {} \;
# Also check if there are any dependencies in the hailo-pci Config.in
cat buildroot-external/package/hailo-pci/Config.in
# Check the main Buildroot config for any related dependencies
cat buildroot-external/Config.in
Length of output: 67540
Script:
#!/bin/bash
# Let's check for kernel config fragments specifically for PCI and Hailo
fd -t f . buildroot-external/kernel/v6.6.y/ -x grep -l "CONFIG_PCI" {} \;
# Check if there are any Hailo-related kernel configs in defconfig
rg "CONFIG_HAILO|CONFIG_PCI" buildroot-external/configs/ova_defconfig
# Check for any PCI-related dependencies in Hailo packages
cat buildroot-external/package/hailo-pci/Config.in
Length of output: 519
Summary by CodeRabbit
New Features
Bug Fixes
Documentation
Chores