Prepare 14.1.rc1 #3748
Prepare 14.1.rc1 #3748
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 multiple updates across the Home Assistant Operating System repository. The changes primarily focus on kernel version updates, configuration modifications, and the addition of new packages like Hailo PCI and Hailo8 firmware. Several configuration files have been updated to use a newer Linux kernel version (6.6.66), and new package configurations have been added to support Hailo devices. The workflow files have also been modified to enhance build and version management processes, including manual workflow dispatch and more flexible version handling. Changes
Sequence DiagramsequenceDiagram
participant Workflow as GitHub Workflow
participant Build as Build Process
participant Kernel as Kernel Configuration
participant Packages as Package Management
Workflow->>Build: Trigger build
Build->>Kernel: Select kernel version 6.6.66
Build->>Packages: Add Hailo PCI and Firmware
Packages-->>Build: Install packages
Build->>Workflow: Generate artifacts
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: 2
🔭 Outside diff range comments (1)
.github/workflows/build.yaml (1)
Line range hint
419-451: Enhance version validation and channel managementConsider adding additional safeguards for version management:
- Validate version format against semantic versioning
- Add version compatibility checks between channels
- Implement rollback procedures for failed version bumps
- name: Bump Home Assistant OS ${{ needs.prepare.outputs.channel }} channel version uses: home-assistant/actions/helpers/version-push@master with: key: "hassos[]" key-description: "Home Assistant OS" version: ${{ needs.prepare.outputs.version_full }} channel: ${{ needs.prepare.outputs.channel }} + pre-push-validation: | + if [[ ! "${{ needs.prepare.outputs.version_full }}" =~ ^[0-9]+\.[0-9]+(\.[0-9]+)?(-(dev|beta|rc)[0-9]+)?$ ]]; then + echo "Invalid version format" + exit 1 + fi
🧹 Nitpick comments (10)
.github/workflows/build.yaml (5)
Line range hint
8-15: Consider additional validation for the publish flagWhile the publish flag is properly guarded by repository checks later in the workflow, consider adding environment protection rules to ensure that publishing can only be triggered by authorized users, especially for production releases.
Line range hint
165-171: Enhance visibility of self-signed certificate usageWhile the warning about using a self-signed certificate is logged, consider:
- Adding this warning to the build summary
- Including a visible artifact or label in the final build to indicate it was signed with a self-signed certificate
This helps prevent accidental deployment of development-signed builds to production.
Line range hint
92-112: Enhance board matrix validationThe matrix generation script should include additional validation:
- Check for invalid board identifiers in the input
- Ensure at least one valid board is selected
- Add error messages for invalid configurations
const boards = require('./.github/workflows/matrix.json') +const validBoards = new Set(boards.map(b => b.id)) if ("${{ github.event_name }}" == "release") { return { "board": boards } } const boardFilter = "${{ github.event.inputs.boards }}" if (boardFilter == "") { console.log("Run full build for all boards") return { "board": boards } } else { console.log("Run partial build") const boardSet = new Set(boardFilter.split(",")) + // Validate board identifiers + const invalidBoards = [...boardSet].filter(b => !validBoards.has(b)) + if (invalidBoards.length > 0) { + throw new Error(`Invalid board identifiers: ${invalidBoards.join(", ")}`) + } const buildBoards = boards.filter(b => boardSet.has(b.id)) + if (buildBoards.length === 0) { + throw new Error("No valid boards selected for build") + } return { "board": buildBoards } }
Line range hint
246-259: Enhance build error handling and reportingConsider improving the build step error handling:
- Add timeout to prevent hung builds
- Capture and parse build logs for common errors
- Include build errors in the workflow summary
docker run --rm --privileged \ -e BUILDER_UID="${BUILDER_UID}" -e BUILDER_GID="${BUILDER_GID}" \ -v "${GITHUB_WORKSPACE}:/build" \ -v "/mnt/cache:/cache" \ -v "/mnt/output:/build/output" \ + --timeout 4h \ ${{ needs.prepare.outputs.build_container_image }} \ - make BUILDDIR=/build ${{ matrix.board.defconfig }} + bash -c ' + make BUILDDIR=/build ${{ matrix.board.defconfig }} 2>&1 | tee build.log + exit ${PIPESTATUS[0]} + ' + +# Parse and summarize build errors +- name: Analyze build logs + if: always() + run: | + if [ -f build.log ]; then + echo "## Build Errors" >> $GITHUB_STEP_SUMMARY + grep -A 5 "^make.*Error " build.log >> $GITHUB_STEP_SUMMARY || true + fi
Line range hint
279-285: Optimize artifact storage and transferConsider implementing artifact size optimization:
- Add size limits to prevent oversized artifacts
- Implement parallel uploads for large artifacts
- Add artifact cleanup for old development builds
buildroot-external/package/hailo-pci/Config.in (1)
4-7: Enhance help text with version requirementsThe help text could be more specific about kernel version requirements and hardware compatibility details.
Consider expanding the help text:
help Kernel driver for interacting with Hailo devices over PCIe. Used e.g. for Hailo-8(L) PCIe device found e.g. on Raspberry Pi AI Kit and Raspberry Pi AI HAT+. + Requires Linux kernel 6.6 or later. + Compatible with Hailo-8(L) PCIe devices revision X.X and above.buildroot-external/rootfs-overlay/usr/lib/systemd/system/raucdb-first-boot.service (1)
11-11: Add error handling and loggingThe rm command should log its outcome for debugging purposes.
Consider this improvement:
-ExecStart=/bin/rm -f /mnt/data/rauc.db +ExecStart=/bin/sh -c 'rm -f /mnt/data/rauc.db && echo "Successfully removed rauc.db" || echo "Failed to remove rauc.db"'buildroot-external/kernel/v6.6.y/hassos.config (1)
158-158: LGTM: TCP MSS target support added as loadable moduleThe addition of TCPMSS target support enhances network packet handling capabilities, particularly useful for VPN and MTU mismatch scenarios. The module configuration (=m) is consistent with other netfilter options.
This module will help prevent fragmentation issues in VPN setups and when dealing with different MTU sizes across network segments.
buildroot-external/configs/odroid_n2_defconfig (1)
19-19: Architectural Consistency: Well-coordinated kernel version update.The systematic update of the kernel version to 6.6.66 across all board configurations demonstrates good architectural practices:
- Maintains version consistency across different hardware platforms
- Preserves compatibility with existing kernel configuration fragments
- Follows a coordinated approach for the 14.1.rc1 release preparation
buildroot-external/configs/generic_aarch64_defconfig (1)
173-174: LGTM: Hailo support for generic ARM64Adding Hailo8 firmware and PCI support to the generic ARM64 configuration ensures broad platform compatibility.
Consider documenting the minimum hardware requirements and any platform-specific considerations for Hailo8 support in the repository's documentation.
📜 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 (14)
- buildroot-external/package/hailo8-firmware/Config.in
- buildroot-external/board/raspberrypi/kernel.config
- buildroot-external/meta
- buildroot-external/configs/odroid_xu4_defconfig
- buildroot
- buildroot-external/configs/odroid_c2_defconfig
- buildroot-external/configs/rpi4_defconfig
- buildroot-external/configs/rpi3_64_defconfig
- buildroot-external/configs/rpi4_64_defconfig
- buildroot-external/package/hailo8-firmware/hailo8-firmware.mk
- buildroot-external/package/hailo-pci/hailo-pci.hash
- buildroot-external/configs/odroid_m1_defconfig
- buildroot-external/package/hailo8-firmware/hailo8-firmware.hash
- 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 (22)
.github/actions/bump-rpi-imager-version/action.yml (2)
86-86: LGTM! Addition of Yellow device follows established patterns.
The implementation correctly extends version bumping support to the Yellow device, maintaining consistency with other supported devices (RPi 3/4/5).
86-86: Verify Yellow device release artifact naming convention.
Let's verify that the release artifacts for the Yellow device follow the expected naming pattern haos_yellow-${version}.img.xz.
✅ Verification successful
Release artifacts for Yellow device follow the expected naming convention
The verification confirms that:
- Latest release artifact follows the pattern
haos_yellow-${version}.img.xz - The manifest in
rpi-imager-haos.jsoncorrectly references this naming pattern - Both the release artifact and manifest are aligned with version 14.0
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify release artifact naming convention for Yellow device
# Check recent releases for Yellow device artifacts
gh api \
-H "Accept: application/vnd.github+json" \
/repos/home-assistant/operating-system/releases/latest \
--jq '.assets[].name' | grep -E "haos_yellow-.*\.img\.xz$"
# Verify JSON manifest structure
curl -s https://raw.githubusercontent.com/home-assistant/version/master/rpi-imager-haos.json | \
jq '.os_list[] | select(.name | contains("Yellow"))'
Length of output: 1891
buildroot-external/configs/tinker_defconfig (2)
Line range hint 1-150: Configuration looks good
The kernel version update is compatible with:
- The kernel config fragments in
kernel/v6.6.y/ - The enabled hardware support and drivers
- The U-Boot version 2024.01
- The system architecture (ARM Cortex-A17)
21-21: Verify Linux kernel version 6.6.66
The kernel version update from 6.6.63 to 6.6.66 aligns with the PR objectives. Let's verify the version and check for any potential issues.
✅ Verification successful
Linux kernel version 6.6.66 is valid and consistently used
The kernel version update is verified:
- Version 6.6.66 is an official longterm release from kernel.org (released on 2024-12-14)
- The version is consistently used across all defconfig files in the repository
- The version bump from 6.6.63 to 6.6.66 is a minor update within the same stable series
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify Linux kernel version 6.6.66 and its compatibility
# Check if the kernel version exists in kernel.org
curl -s https://www.kernel.org/releases.json | jq -r '.releases[] | select(.version == "6.6.66")'
# Look for any known security issues for this kernel version
gh api graphql -f query='
{
securityVulnerabilities(first: 5, ecosystem: LINUX, package: "linux", severity: [CRITICAL, HIGH]) {
nodes {
advisory {
summary
severity
publishedAt
}
vulnerableVersionRange
firstPatchedVersion {
identifier
}
}
}
}'
# Check if this version is consistently used across other defconfigs
rg "BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE=\"6.6.66\"" buildroot-external/configs/
Length of output: 3160
.github/workflows/build.yaml (1)
139-139: LGTM: Docker buildx setup is up to date
The update to docker/[email protected] is appropriate and current.
buildroot-external/rootfs-overlay/usr/lib/systemd/system/raucdb-first-boot.service (1)
3-4: Verify service dependencies
The service ordering looks correct, but let's verify that these services exist and their relationships are properly defined.
✅ Verification successful
Service dependencies are correctly defined and no circular dependencies found
The verification shows that:
- All referenced services exist in the system
- The dependency chain is properly ordered:
rauc.service->raucdb-first-boot.service->raucdb-update.service->hassos-supervisor.service
- No circular dependencies are present between these services
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for related RAUC services
fd -e service . buildroot-external/rootfs-overlay/usr/lib/systemd/system/ -x grep -l "rauc"
# Verify no circular dependencies
for service in $(fd -e service . buildroot-external/rootfs-overlay/usr/lib/systemd/system/ -x grep -l "rauc"); do
echo "=== $service ==="
grep -E "^(Before|After)=" "$service"
done
Length of output: 1903
buildroot-external/Config.in (1)
6-6: LGTM: Hailo PCI package configuration added correctly
The addition follows the existing pattern and maintains alphabetical ordering.
buildroot-external/configs/rpi5_64_defconfig (2)
20-20: LGTM: Kernel source pinned to specific commit
Moving from a dated stable tag to a specific commit hash improves build reproducibility.
147-147: LGTM: Hailo PCI support enabled for RPi5
Enables Hailo PCI support, consistent with the broader changes in this PR for Hailo device support.
buildroot-external/configs/khadas_vim3_defconfig (1)
19-19: LGTM: Kernel version update is consistent.
The kernel version update to 6.6.66 aligns with the PR objectives for the 14.1.rc1 release.
Let's verify the kernel version compatibility with the configuration fragments:
✅ Verification successful
Kernel version update is compatible with configuration fragments
All required kernel configuration fragments (hassos.config, docker.config, device-support.config, and device-support-wireless.config) are present in the correct path buildroot-external/kernel/v6.6.y/, confirming compatibility with the updated kernel version 6.6.66.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify kernel config fragments exist and are compatible
# Test: Check if the kernel config fragments exist in the specified path
fd -t f "hassos.config|docker.config|device-support.config|device-support-wireless.config" "kernel/v6.6.y/"
Length of output: 209
Script:
#!/bin/bash
# Let's first check if the kernel configuration directory exists and its location
fd -t d "kernel"
# Then search for config fragments across the repository
fd -t f "hassos.config|docker.config|device-support.config|device-support-wireless.config"
Length of output: 599
buildroot-external/configs/odroid_c4_defconfig (1)
19-19: LGTM: Consistent kernel version update.
The kernel version update to 6.6.66 maintains consistency across configurations.
buildroot-external/configs/odroid_n2_defconfig (1)
19-19: LGTM: Kernel version update verified.
The kernel version update to 6.6.66 is consistent with other configurations and includes board-specific kernel fragments.
Let's verify the board-specific kernel configuration:
✅ Verification successful
Kernel version update and configuration verified
The kernel version update to 6.6.66 is properly configured with all necessary kernel fragments:
- Base config: buildroot-external/board/hardkernel/kernel-amlogic.config
- Board-specific config: buildroot-external/board/hardkernel/odroid-n2/kernel.config
- Common v6.6.y fragments: hassos.config, docker.config, device-support.config, device-support-wireless.config
All required kernel configuration files exist in the repository and are properly referenced in the defconfig.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify board-specific kernel configuration
# Test: Check if the board-specific kernel config exists and is compatible
fd -t f "kernel.config" "board/hardkernel/odroid-n2/"
Length of output: 166
Script:
#!/bin/bash
# Let's first check if the board directory exists and its correct path
fd -t d "odroid"
# Then look for any kernel config files in the repository
fd -t f "kernel.*config"
# Also check the defconfig content to understand the kernel config references
cat buildroot-external/configs/odroid_n2_defconfig
Length of output: 7727
buildroot-external/configs/rpi2_defconfig (1)
21-21: Verify the specified kernel commit's stability and contents
The change from a dated stable release to a specific commit hash requires verification of the commit's contents and stability.
✅ Verification successful
Let me gather more information about this commit's relationship to stable branches and recent activity.
Let me check one more thing about the parent commit and branch status.
Kernel commit appears to be a stable feature addition
The specified commit (dd2394360860d15146c96635796a75b05bb32b61) from November 19, 2024:
- Adds FIFO-related methods to rp1-pio, which is a focused and contained feature addition
- Is properly signed-off by a Raspberry Pi maintainer
- Follows a stable parent commit that includes DRM driver improvements
- Shows no subsequent fixes or issues in recent commits
- Represents an incremental improvement rather than a major change
The change from a dated stable release to this specific commit appears to be safe.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify the kernel commit's contents and relationship to stable branch
# Fetch commit message and changes
gh api \
-H "Accept: application/vnd.github+json" \
repos/raspberrypi/linux/commits/dd2394360860d15146c96635796a75b05bb32b61 \
--jq '.commit.message'
# Check if this commit is referenced in any tags
gh api \
-H "Accept: application/vnd.github+json" \
repos/raspberrypi/linux/tags \
--jq '.[] | select(.commit.sha == "dd2394360860d15146c96635796a75b05bb32b61") | .name'
Length of output: 468
Script:
#!/bin/bash
# Check if this commit is part of stable branches and recent activity
# Get the commit date and branch information
gh api \
-H "Accept: application/vnd.github+json" \
repos/raspberrypi/linux/commits/dd2394360860d15146c96635796a75b05bb32b61 \
--jq '{date: .commit.author.date, parents: [.parents[].sha]}'
# Get recent commits to see if there are any fixes or issues
gh api \
-H "Accept: application/vnd.github+json" \
repos/raspberrypi/linux/commits \
--jq '[.[] | select(.commit.message | contains("rp1-pio"))] | .[0:3] | .[] | {date: .commit.author.date, message: .commit.message}'
Length of output: 485
Script:
#!/bin/bash
# Check parent commit and branch information
# Get the parent commit info
gh api \
-H "Accept: application/vnd.github+json" \
repos/raspberrypi/linux/commits/57b528e557890f25e010b6bc7356b5a716c79db2 \
--jq '{date: .commit.author.date, message: .commit.message}'
# Get branch information where this commit exists
gh api \
-H "Accept: application/vnd.github+json" \
repos/raspberrypi/linux/branches \
--jq '.[] | select(.commit.sha == "dd2394360860d15146c96635796a75b05bb32b61") | .name'
Length of output: 884
buildroot-external/configs/rpi3_defconfig (1)
21-21: LGTM - Consistent with rpi2_defconfig
The change maintains consistency with rpi2_defconfig, using the same kernel commit hash.
buildroot-external/configs/odroid_m1s_defconfig (2)
Line range hint 21-24: Verify kernel configurations for USB and NVMe features
Given the PR objectives mention USB storage quirks and NVMe disk usage, verify the kernel configurations support these features.
✅ Verification successful
Kernel configurations for USB storage and NVMe features are properly configured
The kernel configurations show appropriate support for both USB storage and NVMe features:
- USB Storage (CONFIG_USB_STORAGE=y) and USB Attached SCSI (CONFIG_USB_UAS) are enabled
- NVMe support (CONFIG_BLK_DEV_NVME) is enabled with additional features like multipath and HWMON support
While there's no explicit JMicron JMS583 quirk configuration in the kernel configs, USB storage quirks are typically handled through kernel boot parameters or udev rules rather than kernel config options.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify USB and NVMe related kernel configurations
# Check for USB storage and NVMe related configs
rg -A 5 "USB_STORAGE|NVME" "kernel/v6.6.y/*.config"
# Look for JMicron related configurations
rg "JMS583|QUIRK" "kernel/v6.6.y/*.config"
Length of output: 224
Script:
#!/bin/bash
# Let's first find the actual kernel config files
fd "kernel.*config$" --type f
# Then check their content for USB storage and NVMe configurations
fd "kernel.*config$" --type f --exec rg -A 5 "USB_STORAGE|NVME" {}
# Look for JMicron related configurations
fd "kernel.*config$" --type f --exec rg "JMS583|QUIRK" {}
Length of output: 3083
19-19: Verify changelog between kernel versions 6.6.63 and 6.6.66
The kernel version bump requires verification of changes and potential security fixes.
✅ Verification successful
Kernel version update is part of coordinated system-wide update
The version change from 6.6.63 to 6.6.66 is part of a coordinated system-wide kernel update, as evidenced by:
- The same version (6.6.66) is used across multiple board configurations including ODROID-M1S, ODROID-C4, Green, OVA, and others
- There's a dedicated update script (
update-kernel-upstream.sh) that handles synchronized kernel version updates across all configurations - The update process includes automatic generation of changelog links for version increments
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for significant changes between kernel versions
# Search for security fixes in kernel config fragments
rg -A 5 "SECURITY" "kernel/v6.6.y/*.config"
# Look for any CVE mentions in kernel config
rg "CVE-" "kernel/v6.6.y/"
# Check kernel configuration fragments for any relevant changes
cat $(rg -l "" "kernel/v6.6.y/*.config")
Length of output: 292
Script:
#!/bin/bash
# Let's check if there are any kernel-related configuration files or documentation
# that might help us understand the kernel version choices
# Search for kernel version references in config files
fd -e defconfig -e config . | xargs rg "BR2_LINUX_KERNEL.*VERSION"
# Look for kernel-related documentation
fd "README|CHANGELOG" . | xargs rg -i "kernel|linux" -A 3
# Check for any kernel patches or version-specific files
fd -e patch . | xargs rg -l "6\.6\."
# Search for kernel configuration logic
rg "BR2_LINUX_KERNEL.*VERSION" -A 5
Length of output: 20711
Script:
#!/bin/bash
# Let's check for documentation about kernel versions and update process
# Check for kernel documentation
fd "kernel.md" . | xargs cat
# Look for update scripts and their documentation
fd "update.*kernel" . | xargs cat
# Check for any changelog or version tracking
rg -A 3 "6\.6\.(63|66)" .
Length of output: 12950
buildroot-external/configs/green_defconfig (1)
19-19: Verify the Linux kernel version update
The kernel version has been updated to 6.6.66. Let's verify this is the latest stable version in the 6.6.x series.
✅ Verification successful
Linux kernel version 6.6.66 is the latest stable version
The version update to 6.6.66 in the defconfig file is correct as it matches the latest stable release in the 6.6.x series according to kernel.org.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check latest stable kernel version in the 6.6.x series
curl -s https://www.kernel.org/releases.json | jq -r '.releases[] | select(.version | startswith("6.6.")) | .version'
Length of output: 126
buildroot-external/configs/yellow_defconfig (2)
159-160: LGTM: Hailo support addition
The addition of Hailo8 firmware and PCI support aligns with the PR objectives for adding Hailo-8 support.
20-20: Verify the Raspberry Pi kernel commit hash
The kernel source has been updated to a specific commit. Let's verify this commit is the latest stable one from the Raspberry Pi kernel repository.
buildroot-external/configs/generic_aarch64_defconfig (1)
19-19: LGTM: Kernel version update
The kernel version update to 6.6.66 is consistent with other configuration files.
buildroot-external/configs/generic_x86_64_defconfig (1)
19-19: Verify kernel version update implications
The kernel update to 6.6.66 aligns with the PR objectives. However, given this is a significant version jump, we should verify there are no breaking changes.
✅ Verification successful
Kernel version update is consistently applied across all configurations
The verification shows that:
- The kernel version 6.6.66 is consistently updated across all board configurations
- Existing kernel patches are board-specific and focus on hardware support rather than version-specific features
- Kernel configs maintain standard configurations without version-specific dependencies
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for any kernel config changes that might need attention
for config in $(fd "kernel.config$"); do
echo "=== Checking $config ==="
rg -A 3 "^# Linux/x86 6\.6\." "$config" || true
done
# Check for any kernel-related patches that might need updating
for patch in $(fd "\.patch$" "buildroot-external/patches/kernel"); do
echo "=== Checking $patch ==="
cat "$patch" | head -n 10
done
Length of output: 3099
Script:
#!/bin/bash
# Let's check for kernel-related patches in the correct location and any kernel version references
echo "=== Checking for kernel patches ==="
fd -e patch -e patch.* . | grep -i "kernel"
echo -e "\n=== Checking kernel version references ==="
rg "BR2_LINUX_KERNEL.*VERSION" buildroot-external/configs/
echo -e "\n=== Checking kernel configs for version info ==="
for config in $(fd "kernel.config$"); do
echo "=== $config ==="
head -n 5 "$config" || true
done
Length of output: 8487
buildroot-external/configs/ova_defconfig (1)
19-19: LGTM! Changes are consistent with generic_x86_64_defconfig
The kernel version update and Hailo support addition mirror the changes in generic_x86_64_defconfig, maintaining consistency across configurations.
Also applies to: 178-179
| HAILO_PCI_VERSION = v4.19.0 | ||
| HAILO_PCI_SITE = $(call github,hailo-ai,hailort-drivers,$(HAILO_PCI_VERSION)) |
There was a problem hiding this comment.
💡 Codebase verification
Update driver version to latest release for kernel 6.6 compatibility
Based on the evidence found:
- The current v4.19.0 version is too old for kernel 6.6.66
- There's an issue mentioning compatibility work for kernels 6.4 and 6.5
- The driver requires explicit kernel version compatibility
Recommend updating to a newer version of the Hailo driver that explicitly supports kernel 6.6. The current version v4.19.0 is likely to have compatibility issues with the target kernel version 6.6.66.
🔗 Analysis chain
Verify Hailo driver version compatibility
The PR objectives mention kernel version 6.6.66, but this driver is pinned to v4.19.0. Please verify compatibility between these versions.
Let me try to find more information about kernel compatibility by checking the driver source code and documentation.
Let me try one more search specifically in the driver's repository to check kernel compatibility.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check Hailo driver version compatibility information
gh api repos/hailo-ai/hailort-drivers/releases/tags/v4.19.0 | jq -r '.body' | grep -i "kernel"
# Check if there are newer versions available
gh api repos/hailo-ai/hailort-drivers/releases | jq -r '.[].tag_name' | sort -V | tail -n 5
Length of output: 226
Script:
#!/bin/bash
# Check README and documentation files for kernel compatibility info
fd -e md -e txt | xargs rg -i "kernel|linux" -A 2
# Check kernel version requirements in source files
rg -i "kernel|linux.*version" -g "*.c" -g "*.h" -A 2
# Look specifically in the PCIe driver directory
fd . -t f -p "pcie.*Makefile|pcie.*\.h" | xargs cat
Length of output: 13074
Script:
#!/bin/bash
# Check the specific version tag in the Hailo repository for kernel compatibility
curl -s https://raw.githubusercontent.com/hailo-ai/hailort-drivers/v4.19.0/linux/pcie/Makefile | grep -i "kernel"
# Check any version requirements in the README at that version
curl -s https://raw.githubusercontent.com/hailo-ai/hailort-drivers/v4.19.0/README.md | grep -i "kernel\|linux" -A 2
# Look for any version compatibility information in the repository's issues
gh api repos/hailo-ai/hailort-drivers/issues?state=all | jq -r '.[] | select(.title | test("kernel|version"; "i")) | {title: .title, body: .body}'
Length of output: 1266
| BR2_PACKAGE_HAILO8_FIRMWARE=y | ||
| BR2_PACKAGE_HAILO_PCI=y |
There was a problem hiding this comment.
💡 Codebase verification
Hailo support configuration needs kernel module configuration
The verification reveals that while the Hailo packages (firmware and PCIe driver) are properly defined, the generic x86_64 kernel configuration is missing the required CONFIG_MEDIA_PCI_HAILO option that was observed in the Raspberry Pi configuration. For proper Hailo-8 support:
- Add
CONFIG_MEDIA_PCI_HAILO=mtobuildroot-external/board/pc/generic-x86-64/kernel.configto enable the kernel module support - Ensure
CONFIG_PCI=yis also present in the kernel config for PCIe support
🔗 Analysis chain
Verify Hailo support configuration completeness
The addition of Hailo8 firmware and PCI support aligns with the PR objectives. Let's verify if all necessary dependencies and configurations are in place.
The previous results showed that Hailo support is mentioned in the Raspberry Pi kernel config but not in the generic x86_64 config. Let's verify if the necessary kernel configurations and package dependencies are properly set up for the generic x86_64 platform.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for any Hailo-related configurations or dependencies
echo "=== Checking Hailo-related kernel configs ==="
for config in $(fd "kernel.config$"); do
rg "HAILO|PCI" "$config" || true
done
# Check for any Hailo-related package definitions
echo "=== Checking Hailo package definitions ==="
rg -A 5 "package.*hailo" "buildroot-external/package/" || true
Length of output: 1921
Script:
#!/bin/bash
# Check for Hailo-related kernel configurations in the generic x86_64 config
echo "=== Checking generic x86_64 kernel config ==="
rg "CONFIG_MEDIA_PCI_HAILO|CONFIG_PCI" "buildroot-external/board/pc/generic-x86-64/kernel.config" || true
# Check for Hailo package definitions and dependencies
echo "=== Checking Hailo package configurations ==="
rg -l "HAILO" "buildroot-external/package/" || true
# Check Config.in files for Hailo-related entries
echo "=== Checking Config.in files for Hailo dependencies ==="
fd "Config.in$" "buildroot-external/package/" -x rg -A 3 "HAILO" {} \;
Length of output: 972
Summary by CodeRabbit
New Features
Updates
Bug Fixes