-
-
Notifications
You must be signed in to change notification settings - Fork 1k
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
Prepare 14.0.rc3 #3708
Prepare 14.0.rc3 #3708
Conversation
* https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.6.63 (cherry picked from commit 22dd060)
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. (cherry picked from commit 489de0b)
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 (cherry picked from commit c514d6b)
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] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> (cherry picked from commit e0ccf39)
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. (cherry picked from commit 9d643ed)
📝 WalkthroughWalkthroughThe pull request introduces updates across several files, primarily focusing on version increments and modifications to the build and configuration processes. Key changes include updating the Docker build action version in the GitHub Actions workflow, incrementing Linux kernel versions from 6.6.62 to 6.6.63 across multiple configuration files, and implementing patches to the device tree source for the Raspberry Pi Compute Module 5 to address specific hardware issues. Additionally, the version suffix in the metadata has been updated, reflecting a progression in the software release candidate stage. Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant GitHub Actions
participant Docker
participant Build System
User->>GitHub Actions: Trigger build
GitHub Actions->>Docker: Build image with updated version
Docker->>Build System: Push built artifacts
Build System->>User: Notify build completion
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 (
|
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: 0
🧹 Outside diff range and nitpick comments (3)
buildroot-external/board/raspberrypi/yellow/patches/linux/0018-ARM-dts-bcm2712-yellow-Disable-SD-SDIO-modes-on-eMMC.patch (1)
32-40
: Clean implementation with clear documentationThe DTS changes are minimal and well-commented. The
no-sdio
andno-sd
flags are the correct properties to use for disabling these modes.Consider documenting this workaround in the board's README or documentation to help future maintainers understand why these modes are disabled.
buildroot-external/board/raspberrypi/yellow/patches/linux/0019-ARM-dts-bcm2712-yellow-Disable-CQE-on-eMMC-interface.patch (1)
43-49
: Clean removal of CQE supportThe change is minimal and focused, only removing the
supports-cqe
property while preserving other essential eMMC capabilities like HS400 mode.Consider adding a comment in the DTS file explaining why CQE is disabled, similar to the SD/SDIO modes comment in patch 0018.
buildroot-external/board/raspberrypi/yellow/patches/linux/0020-ARM-dts-bcm2712-yellow-Disable-rpi_rtc.patch (1)
25-29
: Clean implementation with clear documentationThe DTS changes are minimal and well-documented. The comment clearly explains why the RTC is being disabled.
Consider documenting the RTC hardware configuration in the board's documentation to help users understand which RTC they should rely on.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (18)
.github/workflows/build.yaml
(1 hunks)Documentation/kernel.md
(1 hunks)buildroot-external/board/raspberrypi/yellow/patches/linux/0018-ARM-dts-bcm2712-yellow-Disable-SD-SDIO-modes-on-eMMC.patch
(1 hunks)buildroot-external/board/raspberrypi/yellow/patches/linux/0019-ARM-dts-bcm2712-yellow-Disable-CQE-on-eMMC-interface.patch
(1 hunks)buildroot-external/board/raspberrypi/yellow/patches/linux/0020-ARM-dts-bcm2712-yellow-Disable-rpi_rtc.patch
(1 hunks)buildroot-external/configs/generic_aarch64_defconfig
(1 hunks)buildroot-external/configs/generic_x86_64_defconfig
(1 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
(1 hunks)buildroot-external/configs/tinker_defconfig
(1 hunks)buildroot-external/meta
(1 hunks)
✅ Files skipped from review due to trivial changes (11)
- buildroot-external/meta
- buildroot-external/configs/generic_aarch64_defconfig
- buildroot-external/configs/generic_x86_64_defconfig
- buildroot-external/configs/odroid_xu4_defconfig
- buildroot-external/configs/ova_defconfig
- buildroot-external/configs/green_defconfig
- buildroot-external/configs/odroid_c4_defconfig
- buildroot-external/configs/odroid_m1s_defconfig
- buildroot-external/configs/odroid_m1_defconfig
- buildroot-external/configs/khadas_vim3_defconfig
- Documentation/kernel.md
🔇 Additional comments (7)
buildroot-external/configs/odroid_c2_defconfig (1)
19-19
: LGTM: Kernel version update is consistent with PR objectives
The kernel version update to 6.6.63 aligns with the PR objectives and maintains compatibility with existing kernel configuration fragments.
✅ Verification successful
LGTM: Kernel version update is consistent with PR objectives
The kernel version update to 6.6.63 aligns with the PR objectives. I've verified that all required kernel configuration fragments exist in the correct location at buildroot-external/kernel/v6.6.y/
, including:
- hassos.config
- docker.config
- device-support.config
- device-support-wireless.config
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Verify kernel config fragments exist and are valid for v6.6.y
for fragment in hassos.config docker.config device-support.config device-support-wireless.config; do
if ! [ -f "kernel/v6.6.y/$fragment" ]; then
echo "Missing kernel config fragment: $fragment"
exit 1
fi
done
Length of output: 249
Script:
#!/bin/bash
# Let's first check if the kernel config fragments exist in a different location
fd -t f -e config . | grep -i "kernel.*config"
Length of output: 1536
buildroot-external/configs/tinker_defconfig (1)
21-21
: LGTM: Kernel version update matches system-wide changes
The kernel version update to 6.6.63 is consistent with the system-wide update and maintains compatibility with the Tinker Board hardware configuration.
buildroot-external/configs/odroid_n2_defconfig (1)
19-19
: LGTM: Kernel version update with board-specific configuration preserved
The kernel version update to 6.6.63 maintains compatibility with both common and ODROID-N2 specific kernel configurations.
✅ Verification successful
LGTM: Kernel version update with proper board-specific configuration
The kernel version update to 6.6.63 is properly configured with:
- Board-specific kernel config exists at
buildroot-external/board/hardkernel/odroid-n2/kernel.config
- Correctly referenced in defconfig along with common kernel fragments for v6.6.y
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Verify ODROID-N2 specific kernel config exists
if ! [ -f "board/hardkernel/odroid-n2/kernel.config" ]; then
echo "Missing ODROID-N2 specific kernel config"
exit 1
fi
Length of output: 153
Script:
#!/bin/bash
# Let's verify the kernel config fragments in a broader scope
fd "kernel.*config" --type f
# Check if there are any references to ODROID-N2 kernel config in defconfig
rg -i "odroid.*kernel" buildroot-external/configs/odroid_n2_defconfig
Length of output: 1408
buildroot-external/board/raspberrypi/yellow/patches/linux/0018-ARM-dts-bcm2712-yellow-Disable-SD-SDIO-modes-on-eMMC.patch (1)
10-17
: Well-documented rationale for disabling SD/SDIO modes
The patch description clearly explains the issue and the expected improvement in boot time. The confirmation that disabling these modes won't cause harm is reassuring.
Let's verify if there are any known issues or discussions about this eMMC initialization problem in U-Boot:
✅ Verification successful
Verified workaround for eMMC initialization issue
The patch is part of a series of eMMC-related optimizations for the RPi Yellow board. The rationale is well-supported by:
- A subsequent patch (0019) showing that the eMMC interface has other stability issues requiring CQE to be disabled
- Similar eMMC initialization issues observed in other boards (e.g., Hardkernel) requiring frequency limitations
- The change is conservative, only disabling unused modes (SD/SDIO) while keeping core eMMC functionality intact
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for related eMMC initialization issues in U-Boot
rg -i "emmc.*initialization|emmc.*timeout" --type md
Length of output: 54
Script:
#!/bin/bash
# Let's search for any eMMC-related changes or discussions in commit messages and documentation
rg -i "emmc.*boot|emmc.*init|emmc.*timeout" buildroot-external/
# Also check for any related RPi Yellow eMMC discussions
rg -i "yellow.*emmc|emmc.*yellow" buildroot-external/
Length of output: 1758
Script:
#!/bin/bash
# Let's check the related patch that disables CQE on eMMC interface for additional context
cat buildroot-external/board/raspberrypi/yellow/patches/linux/0019-ARM-dts-bcm2712-yellow-Disable-CQE-on-eMMC-interface.patch
# Also check if there are any other eMMC-related patches for RPi Yellow
fd -e patch -p -E ".*bcm2712.*emmc.*" buildroot-external/board/raspberrypi/yellow/patches/
Length of output: 5354
buildroot-external/board/raspberrypi/yellow/patches/linux/0019-ARM-dts-bcm2712-yellow-Disable-CQE-on-eMMC-interface.patch (1)
9-32
: Strong evidence supporting CQE disable decision
The kernel logs provide clear evidence of the I/O hang issues. The patch author has also noted that this is a known issue with SD cards, making this a reasonable fix for eMMC as well.
Let's check for similar CQE-related issues in the kernel:
✅ Verification successful
Verified: CQE disable patch is well-justified
The evidence supports the decision to disable CQE on the eMMC interface:
- The issue is clearly documented with kernel logs showing multiple tasks being blocked
- Our codebase search shows this is the only instance of CQE being explicitly disabled, indicating a targeted fix for a specific hardware issue
- The patch follows the same approach as known SD card CQE issues, making it a reasonable solution for eMMC
- The fix is minimal and focused on the specific problematic interface
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for CQE-related issues in kernel documentation and changelogs
rg -i "cqe.*hang|cqe.*block" --type md
# Check if other board DTS files have disabled CQE
ast-grep --pattern 'supports-cqe;'
Length of output: 77
Script:
#!/bin/bash
# Let's try a broader search for CQE-related issues and configurations
# Search for CQE-related comments or issues in all files
rg -i "cqe.*issue|cqe.*hang|cqe.*disable" -A 2
# Search for CQE-related configurations in DTS files
fd -e dts -e dtsi -x grep -i "cqe" {} \;
# Look for similar patches or discussions
fd -e patch -x grep -i "cqe" {} \;
Length of output: 1914
buildroot-external/board/raspberrypi/yellow/patches/linux/0020-ARM-dts-bcm2712-yellow-Disable-rpi_rtc.patch (1)
9-10
: Clear rationale for disabling CM5's RTC
The explanation that Yellow has its own I2C RTC and cannot power CM5's VBAT pin is straightforward and hardware-specific.
Let's verify the I2C RTC configuration:
✅ Verification successful
Verified: Yellow board uses PCF85063A I2C RTC, making CM5's RTC redundant
The codebase confirms that:
- Yellow board has a dedicated NXP PCF85063A RTC chip connected via I2C (address 0x51)
- This hardware configuration justifies disabling the CM5's built-in RTC that cannot be powered
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for I2C RTC configuration in the DTS files
ast-grep --pattern 'rp1_i2c3 {
$$$
rtc@$_ {
$$$
}
}'
Length of output: 64
Script:
#!/bin/bash
# Let's try a broader search for RTC configurations in DTS files
rg -l "rtc@" buildroot-external/board/raspberrypi/yellow/
# Also search for I2C bus configurations
rg -l "i2c" buildroot-external/board/raspberrypi/yellow/
# Check if there are any other DTS files that might contain the RTC config
fd . buildroot-external/board/raspberrypi/yellow/ -e dts -e dtsi
Length of output: 1265
Script:
#!/bin/bash
# Let's examine the RTC configuration in patch 0008 which adds the NXP PCF85063A RTC
rg -A 10 "rtc@" buildroot-external/board/raspberrypi/yellow/patches/linux/0008-ARM-dts-bcm2711-yellow-add-NXP-PCF85063A-RTC.patch
# Also check the I2C configuration in config.txt
cat buildroot-external/board/raspberrypi/yellow/config.txt | grep -i "i2c"
Length of output: 335
.github/workflows/build.yaml (1)
147-147
: LGTM! Minor version update of docker/build-push-action.
The update from v6.9.0 to v6.10.0 is a safe maintenance release that keeps the action up to date with the latest fixes.
Let's verify the builder image creation works with the updated action:
✅ Verification successful
✅ Docker build action update verified successfully
The latest workflow run from December 2nd, 2024 completed with a "success" status, confirming that the builder image creation works correctly with the updated docker/build-push-action@v6.10.0.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify the latest successful builder image creation
# Note: This helps confirm the action update didn't break the build process
# Check the latest workflow run status for the builder image
gh api \
-H "Accept: application/vnd.github+json" \
repos/home-assistant/operating-system/actions/workflows/build.yaml/runs \
--jq '.workflow_runs[0] | select(.conclusion != null) | {status: .conclusion, created_at: .created_at}'
Length of output: 282
Summary by CodeRabbit
New Features
Bug Fixes
Documentation
Chores