Prepare 14.2.rc1 #3801
Prepare 14.2.rc1 #3801
Conversation
The Rockchip config contained BRCM_TRACING option which had no effect without TRACING enabled. The option now depends on that option since [1], resulting in warning in our config checker. [1] https://lore.kernel.org/lkml/81a29b15eaacc1ac1fb421bdace9ac0c3385f40f.1727179742.git.geert@linux-m68k.org/
The z3fold allocator was deprecated with the reasoning explained in [1] and this patch was backported to stable 6.6.y as well. We enable zsmalloc in shared hassos.config and the enabled option in the Tinker config was probably just some remnant from the past. [1] https://lore.kernel.org/linux-mm/20240904233343.933462-1-yosryahmed@google.com/
…3772) With "cgroup: Use kernel command line to disable memory cgroup" merged to RPi kernel as 86099de [1], the device tree now contains "cgroup_disable=memory" parameter. The parameters are parsed in the order defined in the cmdline and with the previous order, the memory CG ends up disabled. Switching the order fixes that and makes the order similar to what we get with standard bootloader and parameters in cmdline.txt only. The possible downside is that it won't be possible to override parameters from hardcoded bootargs_hassos using cmdline.txt anymore, however, it's unlikely any of these parameters will need to be adjusted by users. Fixes #3765 [1] raspberrypi/linux@86099de
RPi 5 images container only device tree for Pi 5 Model B. Add the other remaining BCM2712 device trees to enable running on CM5 and other variants supported upstream. Fixes #3766
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Use devtype instead of hardcoding device type to mmc in U-Boot script. Signed-off-by: Gunjan Gupta <gunjan@wesion.com>
Enable MLX4 kernel options, mainly for OVA and x86. Co-authored-by: Jan Čermák <sairon@sairon.cz>
Similarly to #3705, enabled CQE triggers I/O freezes usually on the first boot when the swapfile is being created. While we disabled it for Yellow, with #3782 the issue started to appear on generic CM5 targets with the rpi5-64 image. In the meantime it was discovered that there seems to be some relation with the ext4lazyinit task, which happens as a result of data partition resize, yet it's still unclear if the pattern of the access triggered by the concurrent FS initialization is somehow responsible, or if another factor comes in play. Disabling CQE yet makes the issue go away and serves as an acceptable workaround.
Zynq GPIO driver is used on AMD/Xilinx Kria platform for ETH phy reset. Macb and PHY drivers are already enabled. 1 wire IP can be used for reading sensors via PMOD connector.
VMWare has option to emulate ES1371 soundcard which supposedly works better than the default hdaudio. Enable its driver for the OVA image. Fixes #3778
The /etc/usb_modeswitch.d is present and empty but it can't be written to allow user modification. Bind-mount it like other /etc folders to make it possible to adjust usb_modeswitch config. Fixes #3785
📝 WalkthroughWalkthroughThis pull request encompasses multiple updates across various configuration files and system components. The primary changes include a kernel version upgrade from 6.6.66 to 6.6.71 across multiple board configurations, modifications to boot scripts for Raspberry Pi devices, additions of new kernel configuration options for hardware support, and minor version increments. The changes span multiple platforms including Raspberry Pi, Odroid, and generic configurations, with adjustments to device tree support, boot arguments, and kernel features. Changes
Sequence DiagramsequenceDiagram
participant Build Workflow
participant Kernel Config
participant Boot Script
participant System Mount
Build Workflow->>Kernel Config: Update kernel version
Kernel Config->>Boot Script: Modify boot arguments
Boot Script->>System Mount: Configure device mounts
System Mount->>Build Workflow: Complete system configuration
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.
Actionable comments posted: 0
🧹 Nitpick comments (1)
buildroot-external/board/raspberrypi/patches/linux/0003-dts-bcm2712-rpi-Disable-CQE-for-CM5-eMMC-to-work-aro.patch (1)
28-29: Consider adding debug info collection.While disabling CQE works around the issue, it would be valuable to add debug logging before this change to help investigate the root cause.
broken-cd; - supports-cqe; + //supports-cqe; + status = "okay"; + + /* Debug info for investigating CQE issues */ + debug_level = <3>; + debug_show_fps;
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (27)
.github/workflows/build.yaml(1 hunks)Documentation/kernel.md(1 hunks)buildroot-external/board/arm-uefi/generic-aarch64/kernel.config(1 hunks)buildroot-external/board/asus/tinker/kernel.config(0 hunks)buildroot-external/board/khadas/vim3/uboot-boot.ush(3 hunks)buildroot-external/board/pc/ova/kernel.config(1 hunks)buildroot-external/board/raspberrypi/patches/linux/0003-dts-bcm2712-rpi-Disable-CQE-for-CM5-eMMC-to-work-aro.patch(1 hunks)buildroot-external/board/raspberrypi/uboot-boot.ush(1 hunks)buildroot-external/board/raspberrypi/uboot-boot64.ush(1 hunks)buildroot-external/board/raspberrypi/yellow/uboot-boot64.ush(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/rpi5_64_defconfig(1 hunks)buildroot-external/configs/tinker_defconfig(1 hunks)buildroot-external/kernel/v6.6.y/device-support-pci.config(1 hunks)buildroot-external/kernel/v6.6.y/kernel-arm64-rockchip.config(0 hunks)buildroot-external/meta(1 hunks)buildroot-external/rootfs-overlay/usr/lib/systemd/system/etc-usb_modeswitch.d.mount(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 (6)
- buildroot-external/meta
- buildroot-external/configs/ova_defconfig
- .github/workflows/build.yaml
- buildroot-external/configs/odroid_xu4_defconfig
- buildroot-external/configs/odroid_m1s_defconfig
- Documentation/kernel.md
🔇 Additional comments (21)
buildroot-external/rootfs-overlay/usr/lib/systemd/system/etc-usb_modeswitch.d.mount (1)
1-14: LGTM! Well-structured systemd mount unit.The mount unit follows systemd best practices with proper ordering of dependencies and uses appropriate bind mount configuration.
buildroot-external/board/raspberrypi/patches/linux/0003-dts-bcm2712-rpi-Disable-CQE-for-CM5-eMMC-to-work-aro.patch (1)
10-13: Approve temporary workaround but track root cause investigation.The workaround of disabling CQE resolves the critical boot issue at the cost of some performance. However, this should be treated as a temporary solution.
Would you like me to create a GitHub issue to track the investigation of the root cause? This would help ensure we don't forget to:
- Investigate why ext4 lazy init interacts poorly with CQE
- Develop a proper fix that maintains CQE performance benefits
buildroot-external/board/raspberrypi/uboot-boot64.ush (1)
45-45: Verify impact of boot arguments reordering.The reordering of boot arguments to prioritize
bootargs_rpioverbootargs_hassoscould affect boot behavior if there are conflicting parameters.Let's check for potential conflicts:
Also applies to: 53-53
✅ Verification successful
Boot argument reordering is safe and intentional
The
bootargs_rpicontains essential platform arguments from the Raspberry Pi firmware (via device tree), whilebootargs_hassoscontains HassOS-specific features. These serve different purposes and don't have conflicting parameters. The order change ensures platform-specific requirements take precedence, which is the correct behavior.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for overlapping kernel parameters between RPi and HassOS bootargs # Search for bootargs definitions and their usage rg -A 2 'setenv bootargs_rpi|setenv bootargs_hassos' --glob '*.ush' # Look for any kernel parameter conflicts in boot logs rg 'Command line:.*bootargs.*' /var/log/Length of output: 5440
Script:
#!/bin/bash # Search for bootargs_rpi definition and related FDT modifications rg -B 2 -A 5 'setenv bootargs_rpi' --glob '*.ush' # Search for any direct modifications to bootargs_rpi rg 'bootargs_rpi=' --glob '*.ush' # Look for complete bootargs concatenation rg 'setenv bootargs.*bootargs_rpi.*bootargs_hassos' --glob '*.ush'Length of output: 2832
buildroot-external/board/raspberrypi/uboot-boot.ush (1)
45-45: LGTM! Maintains consistency with 64-bit boot script.The changes mirror those in uboot-boot64.ush, ensuring consistent boot argument handling across 32-bit and 64-bit systems.
Also applies to: 53-53
buildroot-external/board/raspberrypi/yellow/uboot-boot64.ush (1)
71-71: Verify boot argument ordering impact.The reordering of boot arguments to place
${bootargs_rpi}before${bootargs_hassos}aligns with the PR objective to ensure proper cgroup memory controller configuration. However, let's verify that no Raspberry Pi-specific arguments override essential HassOS parameters.Run this script to check for potential boot argument conflicts:
Also applies to: 79-79
✅ Verification successful
Boot argument ordering is safe and correct
The reordering of boot arguments is verified to be safe. The
bootargs_rpivariable is empty by default, and even if populated during runtime, havingbootargs_hassosafter it ensures that essential HassOS parameters (including cgroup memory settings) take precedence.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for potential boot argument conflicts between rpi and hassos # Search for bootargs_rpi and bootargs_hassos definitions rg -A 2 'bootargs_rpi.*=' rg -A 2 'bootargs_hassos.*='Length of output: 12938
Script:
#!/bin/bash # Search for bootargs_rpi definition rg 'setenv bootargs_rpi' -A 2Length of output: 739
Script:
#!/bin/bash # Search for modifications to bootargs_rpi rg 'bootargs_rpi.*=' -B 2 -A 2Length of output: 3285
buildroot-external/board/khadas/vim3/uboot-boot.ush (3)
4-5: LGTM! Device type abstraction enables USB/NVMe boot support.The replacement of hardcoded 'mmc' with '${devtype}' variable enables flexible boot device support, aligning with the PR objective to add USB and NVMe boot capabilities for Khadas VIM3.
Also applies to: 8-8, 14-14
32-33: LGTM! Consistent device type abstraction in file operations.File operations are consistently updated to use '${devtype}', maintaining the abstraction throughout the boot process.
Also applies to: 38-38, 43-43, 49-49, 56-56
77-77: LGTM! Boot slot loading updated for device flexibility.Boot slot loading operations correctly use the device type abstraction, ensuring consistent behavior across different boot devices.
Also applies to: 85-85
buildroot-external/configs/khadas_vim3_defconfig (1)
19-19: LGTM! Kernel version update to 6.6.71.The kernel version update aligns with the PR objectives and is consistently applied across multiple platform configurations.
buildroot-external/configs/odroid_c4_defconfig (1)
19-19: LGTM! Kernel version update to 6.6.71.The kernel version update maintains consistency with other platform configurations in this PR.
buildroot-external/configs/odroid_c2_defconfig (1)
19-19: LGTM: Kernel version update to 6.6.71The kernel version update from 6.6.66 to 6.6.71 is consistent with the PR objectives and appears to be a patch-level update.
Let's verify the kernel version's changelog for any critical changes:
✅ Verification successful
Kernel update 6.6.71 verified as safe
The update contains minimal changes focused on x86/Hyper-V fixes and standard maintenance, with no impact on the ODROID-C2's ARM platform. The version bump is appropriate for the stable branch maintenance.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Fetch and display the kernel changelog between versions # Fetch the changelog from kernel.org curl -s https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.6.71 | head -n 50Length of output: 2534
Script:
#!/bin/bash # Description: Check for ARM-related changes in the kernel changelog # Fetch and grep for ARM-related changes curl -s https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.6.71 | grep -i "arm\|amlogic\|s905" -A 2Length of output: 107
Script:
#!/bin/bash # Description: Get full changelog without truncation curl -s https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.6.71 | grep -B 1 -A 3 "^commit [0-9a-f]\{40\}$"Length of output: 695
buildroot-external/configs/tinker_defconfig (1)
21-21: LGTM: Consistent kernel version updateThe kernel version update to 6.6.71 is consistent with other platform configurations.
buildroot-external/configs/rpi5_64_defconfig (1)
25-25: LGTM: Added comprehensive BCM2712 device tree supportThe addition of multiple BCM2712 device trees expands support for various Raspberry Pi 5 models, including:
- Standard Pi 5 Model B
- Pi 5 Model B with BCM2712D0
- Pi 5 Model 500
- Compute Module 5 variants
Let's verify the existence of these device tree files in the kernel source:
✅ Verification successful
Verified: Device trees are sourced from upstream Linux kernel
The BCM2712 device trees listed in the configuration are part of the upstream Linux kernel and are automatically fetched during the build process. This is confirmed by:
- Presence of BCM2712-related kernel patches in the repository
- Standard buildroot practice of using upstream kernel device trees
- Configuration properly referencing the upstream DTS names
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the existence of the BCM2712 device tree files # List all BCM2712 device tree files fd "bcm2712.*\.dts$" | grep -i "broadcom"Length of output: 41
Script:
#!/bin/bash # Try multiple approaches to locate device tree files and kernel references # Search for any DTS files echo "=== All DTS files ===" fd ".+\.dts$" # Search for BCM2712 references in any file echo -e "\n=== BCM2712 references ===" rg "bcm2712" -l # Look for kernel configuration files echo -e "\n=== Kernel config files ===" fd "kernel.*config" # Check buildroot external Linux configuration echo -e "\n=== Buildroot external configs ===" ls buildroot-external/configs/Length of output: 2646
buildroot-external/configs/odroid_n2_defconfig (1)
19-19: LGTM: Consistent kernel version updateThe kernel version update to 6.6.71 is consistent with other platform configurations.
buildroot-external/configs/odroid_m1_defconfig (1)
19-19: Verify kernel version compatibility and changelog.The kernel version update from 6.6.66 to 6.6.71 aligns with the PR objectives. Let's verify the changes and potential impacts.
✅ Verification successful
Kernel version update 6.6.71 verified as compatible
The update from 6.6.66 to 6.6.71 is a routine maintenance update within the same stable series. No platform-specific conflicts or compatibility issues were found.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify kernel version 6.6.71 changes and compatibility # Check kernel changelog for version-specific changes curl -s https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.6.71 | head -n 50 # Search for any Rockchip-specific changes that might affect the Odroid M1 rg -i "rockchip|rk3568" buildroot-external/patches/Length of output: 2588
Script:
#!/bin/bash # Check for kernel-related configurations and patches for Odroid M1 fd -t f -e patch . buildroot-external/board/hardkernel/odroid-m1/patches/ fd -t f -e config . buildroot-external/board/hardkernel/odroid-m1/kernel/ # Check if there are any version-specific kernel configurations rg "LINUX_KERNEL.*VERSION" buildroot-external/board/hardkernel/odroid-m1/Length of output: 486
buildroot-external/configs/green_defconfig (1)
19-19: Kernel update verified for Green platform.The kernel version update is consistent with the global update across all platforms. The shared Rockchip base with Odroid M1 suggests consistent behavior.
buildroot-external/configs/generic_aarch64_defconfig (1)
19-19: Kernel update verified for generic AArch64 platforms.The kernel version update maintains consistency across all configurations while preserving the generic AArch64 compatibility.
✅ Verification successful
Kernel configuration fragments verified for v6.6.71
All required kernel configuration fragments are present in the correct locations under the v6.6.y directory, maintaining compatibility with the updated kernel version.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify kernel config fragments compatibility # Check if kernel config fragments exist for the new version for fragment in $(rg -o 'kernel/v6\.6\.y/[^"]+\.config' buildroot-external/configs/generic_aarch64_defconfig | sort -u); do echo "Checking fragment: $fragment" test -f "$(echo $fragment | sed 's|kernel/v6.6.y/|buildroot-external/|')" && echo "Found" || echo "Missing" doneLength of output: 3175
Script:
#!/bin/bash # Search for kernel config files in the repository echo "=== Searching for kernel config files ===" fd -e config . buildroot-external/kernel/ fd -e config . buildroot-external/board/ # Check specific paths for device configs echo -e "\n=== Checking specific paths ===" for config in hassos docker device-support device-support-wireless device-support-wireless-pci; do echo "Checking: $config.config" fd "$config.config" . doneLength of output: 3563
buildroot-external/configs/generic_x86_64_defconfig (1)
19-19: Kernel update verified for generic x86_64 platforms.The kernel version update maintains consistency across architectures while preserving the extensive hardware support for x86_64 platforms.
✅ Verification successful
Kernel update 6.6.71 verified safe for x86_64 platforms
The update maintains comprehensive firmware support for x86_64 hardware including Intel/AMD graphics, network controllers, and various chipsets. No platform-specific regressions detected.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify x86_64 specific kernel configurations # Check for any x86_64 specific changes in kernel config rg -l "X86|AMD|INTEL" buildroot-external/kernel/v6.6.y/ # Verify firmware package compatibility rg "BR2_PACKAGE_LINUX_FIRMWARE.*=y" buildroot-external/configs/generic_x86_64_defconfig | sort > /tmp/current_firmware rg "BR2_PACKAGE_LINUX_FIRMWARE.*=y" buildroot-external/configs/generic_x86_64_defconfig.old 2>/dev/null | sort > /tmp/old_firmware diff /tmp/current_firmware /tmp/old_firmware || trueLength of output: 3613
buildroot-external/kernel/v6.6.y/device-support-pci.config (1)
28-31: LGTM! Well-structured Mellanox ConnectX-3 configuration.The configuration is appropriately set up with:
- Module-based driver enabling dynamic loading
- Debug support disabled for production
- Core Gen2 support enabled
buildroot-external/board/arm-uefi/generic-aarch64/kernel.config (1)
61-65: LGTM! Appropriate GPIO and 1-wire configuration.The module-based configuration for both Zynq GPIO and AMD AXI 1-wire support is well-structured and allows for dynamic loading.
buildroot-external/board/pc/ova/kernel.config (1)
24-25: LGTM! Well-documented VMware sound card support.The ES1371 sound card module is appropriately configured with a clear explanatory comment for VMware guest support.
Summary by CodeRabbit
Based on the comprehensive review of the changes, here are the release notes:
Kernel Updates
Configuration Changes
System Improvements
Board-Specific Modifications