-
-
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.2 #3833
Prepare 14.2 #3833
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/[email protected]/
…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 <[email protected]>
Enable MLX4 kernel options, mainly for OVA and x86. Co-authored-by: Jan Čermák <[email protected]>
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
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> (cherry picked from commit a9af9c8)
* buildroot 00e8f09356...ff563b383d (1): > Merge tag '2024.02.10' into 2024.02.x-haos (cherry picked from commit a7cdebf)
* Enable USB-SD convertor on AMD/Xilinx Kria KD240 platform Kria KD240 board is using SD card but SD is connected via onboard USB HUB. USB controller is DWC3 with Xilinx glue logic. Both of these options are enabled but board is using slg7xl45106 for driving usb-hub reset (PCA9570 driver) and USB3.0 requires initialization via PHY_XILINX_ZYNQMP driver. All options should be enabled (=y) and can't be kernel modules because provide access to rootfs. * Add a note for config symbol change in 6.12 Changed in mainline commit 31e7f6c015d9eb35e77ae9868801c53ab0ff19ac --------- Co-authored-by: Jan Čermák <[email protected]> (cherry picked from commit 64ee535)
Build of pam_lastlog.so was disabled by updating to v1.5.3 [1] yet the line wasn't removed from the login modules. In upstream this was resolved by adding a config option for turning the lastlog module and dynamic disabling of the line including it. These changes neither a fix removing the config line were not applied to 2024.02, so cherry-pick them here to fix the issue. * buildroot ff563b383d...3784884466 (2): > package/linux-pam: adjust login pam file for lastlog > package/linux-pam: add menuconfig option to build pam_lastlog.so Fixes #3789 [1] https://github.com/linux-pam/linux-pam/releases/tag/v1.5.3 (cherry picked from commit af7b36e)
📝 WalkthroughWalkthroughThis pull request encompasses a comprehensive update across multiple configuration files and system components. The primary focus is on updating the Linux kernel version from 6.6.66 to 6.6.73 across various board configurations, including Raspberry Pi, Odroid, and generic platforms. Additionally, the changes include kernel configuration modifications, boot script adjustments, and the introduction of a new systemd mount unit for USB modeswitch persistent directory management. 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: Configure boot parameters
Boot Script->>System Mount: Prepare system initialization
System Mount->>System Mount: Mount USB modeswitch persistent directory
The sequence diagram illustrates the high-level flow of the system initialization process, highlighting the key changes introduced in this pull request. 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
🧹 Nitpick comments (3)
buildroot-external/board/khadas/vim3/uboot-boot.ush (2)
77-87
: Consider documenting the partition scheme.While the changes to use ${devtype} are correct, it would be helpful to add comments explaining the partition layout expectations for different storage devices (USB, NVMe, MMC).
Add a comment block like this before the kernel loading section:
+ # Partition layout: + # For MMC/USB/NVMe: + # Partition 5: Kernel A + # Partition 7: Kernel B
Line range hint
4-87
: Overall changes look good with minor improvements needed.The consistent replacement of 'mmc' with '${devtype}' successfully enables booting from different storage devices while maintaining the robust A/B update scheme. The changes align well with the PR objective to support booting from USB and NVMe on the Khadas VIM3.
Consider:
- Verifying ${devtype} initialization
- Adding documentation about partition layout expectations
buildroot-external/board/pc/ova/kernel.config (1)
24-25
: LGTM! Consider documenting this change in the release notes.The addition of ES1371 sound card emulation support for VMware guests is well-placed and correctly implemented as a loadable module. This enhancement aligns with the PR objectives and follows kernel configuration best practices.
Consider adding this sound card support to the release notes or documentation to help users understand the new hardware capabilities available in VMware environments.
📜 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 (10)
- .github/workflows/build.yaml
- buildroot-external/meta
- buildroot-external/configs/ova_defconfig
- buildroot-external/configs/generic_aarch64_defconfig
- buildroot-external/configs/khadas_vim3_defconfig
- buildroot-external/configs/generic_x86_64_defconfig
- buildroot-external/configs/odroid_c2_defconfig
- buildroot-external/configs/odroid_m1_defconfig
- buildroot-external/configs/tinker_defconfig
- Documentation/kernel.md
🔇 Additional comments (22)
buildroot-external/rootfs-overlay/usr/lib/systemd/system/etc-usb_modeswitch.d.mount (3)
1-6
: LGTM! Well-structured unit configuration.The dependencies and ordering constraints are correctly defined to ensure proper initialization sequence.
13-14
: LGTM! Correct target selection.The unit is properly integrated with the
hassos-bind.target
which is appropriate for bind mounts in the system.
7-11
: Verify the source directory existence.The mount unit assumes the existence of
/mnt/overlay/etc/usb_modeswitch.d
. Consider adding a directory creation directive to ensure the mount doesn't fail if the directory is missing.buildroot-external/board/khadas/vim3/uboot-boot.ush (3)
32-38
: LGTM! Configuration loading changes look good.The changes consistently use ${devtype} for loading configuration files while maintaining proper error handling for missing files.
43-56
: LGTM! Robust device tree handling.The changes maintain consistent use of ${devtype} while preserving the robust error handling for device tree overlays.
4-14
: Verify ${devtype} initialization before usage.The change from hardcoded 'mmc' to '${devtype}' improves flexibility for different boot devices (USB, NVMe). However, ensure that ${devtype} is properly initialized before these operations.
Run this script to check for ${devtype} initialization:
✅ Verification successful
The ${devtype} usage is correctly implemented
The script follows U-Boot conventions where ${devtype} is automatically set during boot based on the detected boot device. The implementation is safe as it:
- Properly initializes the device with
${devtype} dev ${devnum}
before any operations- Follows standard U-Boot boot flow patterns
- Uses consistent ${devtype}/${devnum} pairing throughout the script
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for devtype initialization in U-Boot configurations and scripts rg -l "setenv.*devtype" buildroot-external/board/khadas/Length of output: 58
Script:
#!/bin/bash # Search for devtype-related patterns in boot scripts and configs echo "=== Searching for devtype usage ===" rg -p "devtype" buildroot-external/board/khadas/ echo -e "\n=== Checking U-Boot default environment ===" find buildroot-external/board/khadas/ -type f -name "uboot-env" -o -name "uEnv*" | xargs cat echo -e "\n=== Looking for boot script includes ===" rg -p "source|load|run" buildroot-external/board/khadas/vim3/uboot-boot.ushLength of output: 1864
buildroot-external/board/raspberrypi/patches/linux/0003-dts-bcm2712-rpi-Disable-CQE-for-CM5-eMMC-to-work-aro.patch (2)
10-13
: Well-documented temporary workaround for I/O lockups.The comment clearly explains the issue and its conditions: HAOS first boot failures during swap initialization when ext4 lazy init is incomplete. While this is a workaround, it's an acceptable temporary solution given the critical nature of the boot failure.
Consider tracking this as a known issue for future investigation of the root cause. Would you like me to help create an issue to track this?
28-29
: Clean implementation of the CQE disable workaround.The change is minimal and correctly implemented by commenting out the
supports-cqe
property rather than removing it, making it easy to revert when a proper fix is found.buildroot-external/board/raspberrypi/uboot-boot64.ush (1)
45-45
: Verify the impact of bootargs reordering.The order of kernel parameters has been changed to prioritize
bootargs_rpi
overbootargs_hassos
. This change is consistent across all boot scripts (uboot-boot64.ush, uboot-boot.ush, and yellow/uboot-boot64.ush).Let's verify if this change is intentional and understand its impact:
Also applies to: 53-53
✅ Verification successful
Bootargs ordering is correct and intentional
The bootargs ordering with
bootargs_rpi
first is intentionally designed for Raspberry Pi boards to ensure proper hardware initialization. The device tree bootargs must be preserved as the prefix since they contain critical hardware parameters from config.txt. This ordering is consistently implemented across all Raspberry Pi boot scripts (uboot-boot.ush, uboot-boot64.ush, and yellow/uboot-boot64.ush).🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for any kernel parameter conflicts between bootargs_rpi and bootargs_hassos # Search for bootargs_rpi and bootargs_hassos definitions and their usage echo "Searching for bootargs definitions and usage..." rg -A 5 "bootargs_(rpi|hassos)" --type sh # Look for any related discussions or issues echo "Checking for related discussions..." gh issue list --search "bootargs rpi hassos" gh pr list --search "bootargs rpi hassos"Length of output: 320
Script:
#!/bin/bash # First, verify if the boot script files exist echo "Checking for boot script files..." fd -t f "uboot-boot.*\.ush$" # View contents of any found boot scripts echo -e "\nViewing boot script contents..." for file in $(fd -t f "uboot-boot.*\.ush$"); do echo "=== $file ===" cat "$file" echo -e "\n" done # Search for any uboot related files echo "Searching for other uboot related files..." fd "uboot"Length of output: 44763
buildroot-external/board/raspberrypi/uboot-boot.ush (1)
45-45
: Consistent with bootargs reordering in other scripts.The change matches the bootargs reordering in uboot-boot64.ush, maintaining consistency across boot scripts.
Also applies to: 53-53
buildroot-external/board/raspberrypi/yellow/uboot-boot64.ush (1)
71-71
: Consistent with bootargs reordering in other scripts.The change matches the bootargs reordering in the other boot scripts, maintaining consistency across all Raspberry Pi variants.
Also applies to: 79-79
buildroot-external/configs/odroid_c4_defconfig (1)
19-19
: LGTM: Kernel version update is consistent.The update to Linux kernel 6.6.73 is part of a coordinated version bump across all platforms.
Let's verify the kernel version's existence and changelog:
✅ Verification successful
Verified: Linux 6.6.73 is a valid and stable kernel version
The version exists in kernel.org and contains stability improvements, primarily reverting problematic overlayfs changes that were causing issues.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify Linux kernel version 6.6.73 exists and get its changelog # Check if the version exists in kernel.org curl -s https://www.kernel.org/releases.json | jq -r '.releases[] | select(.version == "6.6.73")' # Get the changelog for this version curl -s https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.6.73Length of output: 3150
buildroot-external/configs/rpi5_64_defconfig (1)
25-25
: LGTM: Complete coverage of BCM2712 device trees.The expanded list includes all current BCM2712-based Raspberry Pi variants, improving hardware support coverage.
Let's verify the existence of these device trees in the kernel source:
✅ Verification successful
Verified: All BCM2712 device trees exist in kernel source
All device trees listed in
BR2_LINUX_KERNEL_INTREE_DTS_NAME
are present in the kernel source atarch/arm64/boot/dts/broadcom/
along with their required supporting DTSi files.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the existence of all listed BCM2712 device trees # Extract the kernel tarball location from the config KERNEL_URL=$(grep BR2_LINUX_KERNEL_CUSTOM_TARBALL_LOCATION rpi5_64_defconfig | cut -d'"' -f2) # Download and check DTS files curl -sL "$KERNEL_URL" | tar xz --wildcards "*/arch/arm64/boot/dts/broadcom/bcm2712*.dts" -OLength of output: 341
Script:
#!/bin/bash # Description: Verify the existence of all listed BCM2712 device trees # First verify the config file exists fd -t f "rpi5_64_defconfig" buildroot-external/configs/ # Extract and show kernel version and URL echo "Kernel configuration:" rg "BR2_LINUX_KERNEL_CUSTOM_" buildroot-external/configs/rpi5_64_defconfig # List all BCM2712 DTS files in kernel tree echo -e "\nSearching for BCM2712 DTS files:" fd "bcm2712.*\.dts$" -t fLength of output: 507
Script:
#!/bin/bash set -x KERNEL_URL="https://github.com/raspberrypi/linux/archive/dd2394360860d15146c96635796a75b05bb32b61.tar.gz" TEMP_DIR=$(mktemp -d) echo "Downloading kernel source..." curl -L "$KERNEL_URL" | tar xz -C "$TEMP_DIR" echo -e "\nListing BCM2712 DTS files:" find "$TEMP_DIR" -type f -name "bcm2712*.dts" -exec ls -la {} \; echo -e "\nShowing DTS file contents:" find "$TEMP_DIR" -type f -name "bcm2712*.dts" -exec cat {} \;Length of output: 3443
Script:
#!/bin/bash set -x KERNEL_URL="https://github.com/raspberrypi/linux/archive/dd2394360860d15146c96635796a75b05bb32b61.tar.gz" TEMP_DIR=$(mktemp -d) echo "Downloading kernel source..." curl -L "$KERNEL_URL" | tar xz -C "$TEMP_DIR" echo -e "\nListing extracted directory:" ls -la "$TEMP_DIR" KERNEL_DIR=$(ls "$TEMP_DIR") echo -e "\nSearching for BCM2712 DTS files in arch/arm64/boot/dts/broadcom/:" ls -la "$TEMP_DIR/$KERNEL_DIR/arch/arm64/boot/dts/broadcom/bcm2712*.dts" echo -e "\nShowing DTS file contents:" cat "$TEMP_DIR/$KERNEL_DIR/arch/arm64/boot/dts/broadcom/bcm2712"*.dtsLength of output: 3285
Script:
#!/bin/bash set -x KERNEL_URL="https://github.com/raspberrypi/linux/archive/dd2394360860d15146c96635796a75b05bb32b61.tar.gz" TEMP_DIR=$(mktemp -d) echo "Downloading kernel source..." curl -L "$KERNEL_URL" | tar xz -C "$TEMP_DIR" echo -e "\nListing extracted directory:" ls -la "$TEMP_DIR" KERNEL_DIR=$(ls "$TEMP_DIR") echo -e "\nKernel directory: $KERNEL_DIR" echo -e "\nVerifying directory structure:" ls -la "$TEMP_DIR/$KERNEL_DIR" ls -la "$TEMP_DIR/$KERNEL_DIR/arch" ls -la "$TEMP_DIR/$KERNEL_DIR/arch/arm64" ls -la "$TEMP_DIR/$KERNEL_DIR/arch/arm64/boot/dts/broadcom/" echo -e "\nFinding all DTS files recursively:" find "$TEMP_DIR" -type f -name "*.dts" | grep "bcm27"Length of output: 15084
buildroot-external/configs/odroid_xu4_defconfig (1)
20-20
: LGTM: Kernel version update is consistent.The update to Linux kernel 6.6.73 maintains alignment with other platforms while preserving Exynos-specific configurations.
buildroot-external/configs/odroid_n2_defconfig (1)
19-19
: LGTM: Kernel version update is consistent.The update to Linux kernel 6.6.73 maintains alignment with other platforms while preserving Amlogic-specific configurations.
buildroot-external/configs/odroid_m1s_defconfig (1)
19-19
: LGTM: Kernel version update.The update from 6.6.66 to 6.6.73 aligns with the PR objectives and maintains consistency across platform configurations.
buildroot-external/configs/green_defconfig (1)
19-19
: LGTM: Consistent kernel version update.The kernel version update to 6.6.73 maintains version parity with other platform configurations.
buildroot-external/kernel/v6.6.y/device-support-pci.config (1)
28-31
: LGTM: Well-structured Mellanox ConnectX-3 support.The configuration follows kernel module best practices:
- Network driver as loadable module
- Core Gen2 support built into kernel
- Debug support disabled for production use
buildroot-external/board/arm-uefi/generic-aarch64/kernel.config (4)
61-63
: LGTM: GPIO support additions.The Zynq GPIO driver is appropriately configured as a module, while the PCA9570 GPIO support is built-in, following kernel configuration best practices.
65-66
: LGTM: PHY driver support.The Xilinx ZynqMP PHY driver is correctly configured as built-in support.
72-73
: LGTM: 1-wire support addition.The AMD 1-wire AXI master driver is appropriately configured as a module.
68-70
: Track the TODO for USB configuration update.Note indicates a future change to
CONFIG_USB_ONBOARD_DEV
in kernel 6.12.Let's verify if kernel 6.12 is already released with this change:
Summary by CodeRabbit
Based on the comprehensive summary, here are the release notes:
Kernel Updates
Hardware Support
System Configuration
Build Process
Miscellaneous