Prepare 14.0 #3710
Prepare 14.0 #3710
Conversation
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: Franck Nijhof <frenck@frenck.nl>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Add support for interrupt remapping for IO-APIC and MSI devices as required by some ath12k devices. Fixes: #3621
Bumps [mikepenz/action-junit-report](https://github.com/mikepenz/action-junit-report) from 4 to 5. - [Release notes](https://github.com/mikepenz/action-junit-report/releases) - [Commits](mikepenz/action-junit-report@v4...v5) --- updated-dependencies: - dependency-name: mikepenz/action-junit-report dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
This commit adds support for usb to i2c adapters, the i2c chardev and the bme280 famaily environment sensors
* buildroot d59d09ad38...2ffac68a74 (1): > Merge tag '2024.02.7' into 2024.02.x-haos
* RaspberryPi: Update kernel to 6.6.51 - stable_20241008 * Update rpi-firmware to version for kernel 6.6.51 * buildroot 2ffac68a74...19027bc796 (1): > package/rpi-firmware: bump to version 1.20241008 for kernel 6.6.51
* Move RPi U-Boot patches to version-specific directory We will need to use different series for 2024.10 which would be used as the base for CM5 support. * Remove common.h include from the fileenv cmd It doesn't seem to be used and common.h has been removed in newer U-Boot. * Use U-Boot 2024.10 with BCM2712 PCIe patches for Yellow Use rebased patchset from v2024.01 with the first patch removed. Add patches needed for PCIe initialization and use rpi_arm64_defconfig as the base config for both CM4 and CM5. * Add device tree for CM5 on HA Yellow and adjust config Add device tree definition based on the CM5 device tree with BCM2712D0 changes applied, and add nodes required for the on-board peripherals of Yellow. Currently the difference in serial numbering still requires either changes in this device tree, or userspace changes to create correct symlinks to make HA configuration directly compatible with CM4 on Yellow. * Add config.txt migration for conditional device_tree options * Fix typos and minor issues found by CodeRabbit
The timeout of 90s was introduced before it was ensured that the timesync systemd unit starts after network is online. Now with that, it makes less sense to wait that long - if network is unreachable at the point the time synchronization starts, and the server fails to reply on the first sync, the polling interval is exponentially increased and the benefit of waiting for more attempts is doubtful. Since another synchronization attempt is done after network changes its state, we should rely on that instead of having the 90 seconds interval as a waiting period for plugging the network cable. Worst case, there are other mechanisms that should set the time to a reasonably accurate value, making the NTP sync less importart for most of the cases.
Add iwlwifi-gl firmware, which is required for Intel BE200 card. Targets are generic_aarch64, generic_x86_64 and ova. * buildroot 19027bc796...1d7407c66b (1): > package/linux-firmware: add iwlwifi gl firmware Closes #3643.
The hook was missing in the manifest, enable it conditionally for Yellow and add reminder to remove it once it's not needed.
As stated in the docs [1], post-install hook is not executed if the slot already has an install hook defined. Merge the post-install hook with the install hook to fix CM5 migration for Yellow. [1] https://rauc.readthedocs.io/en/latest/using.html#slot-hooks
* Add Makefile variable for Supervisor channel Allow to set the release channel pre-installed Home Assistant components like Supervisor and add-on are fetched from. This channel is then also used at runtime. * Use choice instead of string variable * Fix channel in Supervisor updater.json config * Add newlines
Add Hailo-8 firmware binary for Rasperry Pi AI accelerators. The version needs to be determined from the Git history of the kernel sources, as the driver source code is included in the RPi downstream kernel and the version string can't be found in the code directly. Fixes #3663
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. (cherry picked from commit 98ac7f0)
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. (cherry picked from commit b288cd2)
* 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 changes in this pull request involve updates to various configuration files, scripts, and documentation across multiple components of the Home Assistant Operating System. Key modifications include enhancements to build workflows in GitHub Actions, updates to kernel versions for various hardware platforms, and the introduction of new features such as NVMe support and improved data partition handling. Additionally, new firmware support for the Hailo-8 device is added, along with updates to existing systemd services and U-Boot commands. These changes collectively improve the system's functionality, compatibility, and maintainability. Changes
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: 7
🧹 Outside diff range and nitpick comments (19)
buildroot-external/board/raspberrypi/patches/uboot/2024.10/0009-reset-reset-brcmstb-rescal-Add-Broadcom-RESCAL-reset.patch (2)
96-108: Improve Error Logging by Using Appropriate Logging FunctionsIn
brcm_rescal_reset_deassert, error messages are printed usingprintf. It is recommended to usedev_err()for error logging to integrate with U-Boot's logging framework.Apply the following changes to improve error handling:
- printf("failed to start SATA/PCIe rescal\n"); + dev_err(rst->dev, "Failed to start SATA/PCIe RESCAL\n");- printf("time out on SATA/PCIe rescal\n"); + dev_err(rst->dev, "Timeout on SATA/PCIe RESCAL\n");
120-124: Use Consistent Logging Functions inbrcm_rescal_reset_of_xlateIn the
brcm_rescal_reset_of_xlatefunction, error messages are printed usingprintf. For consistency and better integration with the logging system, consider usingdev_err().Update the error logging as follows:
- printf("Invalid args_count: %d\n", args->args_count); + dev_err(reset_ctl->dev, "Invalid args_count: %d\n", args->args_count);buildroot-external/board/raspberrypi/patches/uboot/2024.10/0006-nvme-translate-virtual-addresses-into-the-bus-s-addr.patch (1)
145-145: Include header guard forphys2bus.hThe inclusion of
<phys2bus.h>without a corresponding header guard may lead to redundant inclusions or conflicts. Ensure thatphys2bus.hhas proper header guards to prevent compilation issues.If not already present, add header guards in
phys2bus.h:#ifndef _PHYS2BUS_H_ #define _PHYS2BUS_H_ /* contents of phys2bus.h */ #endif /* _PHYS2BUS_H_ */buildroot-external/board/raspberrypi/patches/uboot/2024.10/0005-nvme-Use-pointer-for-CPU-addressed-buffers.patch (1)
69-90: Ensure correct offset calculation withvoid *bufferAfter changing to
void *buffer, make sure that the offset calculations and buffer manipulations correctly handle pointer arithmetic without introducing errors due to pointer type differences.Consider casting the pointer to
uintptr_twhen performing arithmetic to avoid issues:int offset = (uintptr_t)buffer & (page_size - 1);buildroot-external/board/raspberrypi/patches/uboot/2024.10/0010-pci-pcie-brcmstb-Add-basic-support-for-BCM2712-PCIe.patch (2)
61-62: Ensure compliance with the kernel coding styleThe changes introduce significant additions to
pcie_brcmstb.c. Verify that the code follows the kernel coding style guidelines, including indentation, spacing, and naming conventions.Run the following script to check for coding style issues:
#!/bin/bash # Description: Check coding style with Linux kernel's checkpatch.pl # Expected: No significant coding style warnings or errors ./scripts/checkpatch.pl --no-tree --file drivers/pci/pcie_brcmstb.c
183-215: Abstract reset handling for better maintainabilityThe introduction of
brcm_pcie_perst_set_genericandbrcm_pcie_bridge_sw_init_set_genericfunctions helps abstract the reset logic. Ensure that these functions cover all necessary cases and consider whether further generalization or documentation could improve maintainability.Consider documenting the reset sequences for different SoCs to aid future development.
buildroot-external/board/raspberrypi/yellow/patches/linux/0016-ARM-dts-bcm2712-Add-device-tree-for-CM5-on-HA-Yellow.patch (1)
458-462: Optimize boot arguments and console configurationThe
chosennode specifies boot arguments and thestdout-path. Ensure that the boot parameters are optimal for the hardware and that the console is correctly configured for serial communication.Consider reviewing the boot arguments for any deprecated parameters or potential optimizations.
buildroot-external/package/hassio/create-data-partition.sh (1)
28-28: Consider adding error handling for container execution.While the script has set -e, explicit error handling for the Docker exec command would improve robustness.
-docker exec "${container}" sh /build/dind-import-containers.sh "${channel}" +if ! docker exec "${container}" sh /build/dind-import-containers.sh "${channel}"; then + echo "Error: Failed to import containers" + docker stop "${container}" || true + sudo umount "${build_dir}/data/" || true + exit 1 +fibuildroot-external/package/hassio/Config.in (1)
27-41: Consider enhancing channel documentation.While the implementation is correct, the help text could be more descriptive about the implications of each channel choice.
config BR2_PACKAGE_HASSIO_CHANNEL_STABLE bool "Stable" help - Stable channel. + Stable channel - Recommended for production use. + Receives thoroughly tested updates. config BR2_PACKAGE_HASSIO_CHANNEL_BETA bool "Beta" help - Beta channel. + Beta channel - For testing new features. + Receives updates before stable but may have issues. config BR2_PACKAGE_HASSIO_CHANNEL_DEV bool "Dev" help - Dev channel. + Dev channel - For development testing only. + Receives frequent updates, may be unstable.buildroot-external/package/hailo8-firmware/hailo8-firmware.mk (1)
12-14: Consider optimizing the build processThe current implementation copies the file twice:
- From download dir to build dir
- Renaming within build dir
Consider combining these operations to reduce I/O operations.
define HAILO8_FIRMWARE_EXTRACT_CMDS - cp $(HAILO8_FIRMWARE_DL_DIR)/$(HAILO8_FIRMWARE_SOURCE) $(@D) + cp $(HAILO8_FIRMWARE_DL_DIR)/$(HAILO8_FIRMWARE_SOURCE) $(@D)/hailo8_fw.bin endef -define HAILO8_FIRMWARE_BUILD_CMDS - cp $(@D)/$(HAILO8_FIRMWARE_SOURCE) $(@D)/hailo8_fw.bin -endefAlso applies to: 16-18
buildroot-external/board/raspberrypi/patches/uboot/2024.10/0012-pci-pcie-brcmstb-HACK-add-DT-property-for-skipping-d.patch (3)
27-31: Consider documenting the new struct memberThe new
no_probeboolean member instruct brcm_pcieshould be documented with a comment explaining its purpose and relationship to the DT property.enum pcie_soc_base soc_base; int gen; bool ssc; - bool no_probe; + /* Skip device probing when u-boot,no-probe is set in DT */ + bool no_probe;
35-43: Early return could be more descriptiveThe debug message could provide more context about why the probe is being skipped.
if (pcie->no_probe) { - printf("PCIe BRCM: skipping probe\n"); + printf("PCIe BRCM: skipping probe due to u-boot,no-probe in DT\n"); return 0; }
47-52: Document temporary nature of the workaroundThe commit message indicates this is a temporary solution. Consider adding a TODO comment near the property reading to track this technical debt.
pcie->ssc = ofnode_read_bool(dn, "brcm,enable-ssc"); + /* TODO: This is a temporary workaround for RPi 5 PCIe2 initialization issues. + * Should be removed once proper controller initialization is implemented. */ pcie->no_probe = ofnode_read_bool(dn, "u-boot,no-probe");buildroot-external/patches/uboot/0001-CMD-read-string-from-fileinto-env.patch (2)
Line range hint
47-91: Add bounds checking and improve error handlingThe current implementation has several potential security and stability issues:
- No maximum size limit for the file being read
- Potential buffer overflow in string processing
- Limited error handling for string operations
Consider applying these improvements:
int do_fileenv(struct cmd_tbl *cmdtp, int flag, int argc, char * const argv[]) { + #define MAX_FILE_SIZE (64 * 1024) // 64KB limit + int ret; if (argc < 6) return CMD_RET_USAGE; fs_argv[0] = "fatload"; fs_argv[1] = argv[1]; fs_argv[2] = argv[2]; fs_argv[3] = argv[3]; fs_argv[4] = argv[4]; - if (do_fat_fsload(cmdtp, 0, 5, fs_argv) != 0) + ret = do_fat_fsload(cmdtp, 0, 5, fs_argv); + if (ret != 0) { + printf("Error: Failed to load file %s\n", argv[4]); return 1; + } char *addr = (char *)simple_strtoul(argv[3], NULL, 16); size_t size = env_get_hex("filesize", 0); + if (size > MAX_FILE_SIZE) { + printf("Error: File size %zu exceeds maximum allowed size %d\n", + size, MAX_FILE_SIZE); + return 1; + } + + if (!addr) { + printf("Error: Invalid memory address\n"); + return 1; + } + // Prepare string addr[size] = 0x00; char *s = addr; + size_t valid_len = 0; while(*s != 0x00) { if (isprint(*s)) { + valid_len++; s++; } else { *s = 0x00; + break; } + if (valid_len >= size) break; } - return env_set(argv[5], addr); + ret = env_set(argv[5], addr); + if (ret != 0) { + printf("Error: Failed to set environment variable %s\n", argv[5]); + return 1; + } + + return 0; }
Line range hint
88-91: Improve command documentationThe command help text should include more details about limitations and usage.
U_BOOT_CMD( fileenv, 6, 0, do_fileenv, "Read file and store it into env.", - "<interface> <dev:part> <addr> <filename> <envname>\n" - " - Read file from fat32 and store it as env." + "<interface> <dev:part> <addr> <filename> <envname>\n" + " - Read file from fat32 and store it as env.\n" + " - Maximum file size: 64KB\n" + " - Only printable ASCII characters are stored\n" + " - Example: fileenv mmc 0:1 ${loadaddr} config.txt bootargs" );buildroot-external/board/raspberrypi/yellow/patches/linux/0019-ARM-dts-bcm2712-yellow-Disable-CQE-on-eMMC-interface.patch (1)
43-49: Consider documenting the performance impactWhile disabling CQE resolves the hanging issues, it might affect eMMC performance. Consider adding a comment in the DTS to document this trade-off.
&sdio1 { mmc-hs400-1_8v; mmc-hs400-enhanced-strobe; broken-cd; + /* CQE disabled due to random I/O hangs during heavy operations. + * This might reduce performance but improves stability. + * See: https://github.com/home-assistant/operating-system/pull/3710 + */ status = "okay"; };buildroot-external/board/hardkernel/patches/uboot/0001-HACK-mmc-meson-gx-limit-f_max-to-24-MHz-on-the-first.patch (1)
55-68: Consider improving error handling and loggingWhile the fallback logic is correct, consider these improvements:
- Add debug logging for the initial frequency
- Consider adding a retry count to prevent infinite loops
err = mmc_select_mode_and_width(mmc, mmc->card_caps); if (err && mmc->meson_gx_f_max_hack) { + debug("Initial frequency: %d Hz\n", mmc->clock); /* Some eMMCs (namely Kingston) do not initialize at limited frequency. */ printf("Card failed to initialize at %d Hz, disabling meson_gx hack.\n", mmc->clock); mmc->meson_gx_f_max_hack = false; + debug("Retrying with maximum frequency\n"); err = mmc_select_mode_and_width(mmc, mmc->card_caps); }buildroot-external/configs/odroid_c2_defconfig (1)
19-19: Coordinated kernel update across platformsThe synchronized update of kernel version to 6.6.63 across all platforms demonstrates good maintenance practices:
- Consistent kernel version across different hardware platforms
- Staying within the stable 6.6.x series minimizes risk
- Unified update makes testing and maintenance more manageable
Consider documenting the kernel update testing process for different hardware platforms in the project documentation to facilitate future updates.
buildroot-external/configs/generic_aarch64_defconfig (1)
72-72: Added support for Intel GL WiFi firmwareThe addition of
BR2_PACKAGE_LINUX_FIRMWARE_IWLWIFI_GLenhances wireless connectivity support for Intel GL series WiFi adapters.Consider documenting the supported Intel GL WiFi models in the platform documentation to help users verify hardware compatibility.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (63)
.github/workflows/build.yaml(1 hunks).github/workflows/test.yaml(1 hunks)Documentation/kernel.md(1 hunks)buildroot(1 hunks)buildroot-external/Config.in(1 hunks)buildroot-external/board/hardkernel/patches/uboot/0001-HACK-mmc-meson-gx-limit-f_max-to-24-MHz-on-the-first.patch(1 hunks)buildroot-external/board/hardkernel/patches/uboot/0001-HACK-mmc-meson-gx-limit-to-24MHz.patch(0 hunks)buildroot-external/board/pc/generic-x86-64/kernel.config(1 hunks)buildroot-external/board/pc/ova/kernel.config(1 hunks)buildroot-external/board/raspberrypi/cmdline.txt(1 hunks)buildroot-external/board/raspberrypi/patches/uboot/2024.10/0001-rpi-add-NVMe-to-boot-order.patch(1 hunks)buildroot-external/board/raspberrypi/patches/uboot/2024.10/0002-Revert-nvme-Correct-the-prps-per-page-calculation-me.patch(1 hunks)buildroot-external/board/raspberrypi/patches/uboot/2024.10/0003-usb-xhci-brcm-Make-driver-compatible-with-downstream.patch(1 hunks)buildroot-external/board/raspberrypi/patches/uboot/2024.10/0004-nvme-improve-readability-of-nvme_setup_prps.patch(1 hunks)buildroot-external/board/raspberrypi/patches/uboot/2024.10/0005-nvme-Use-pointer-for-CPU-addressed-buffers.patch(1 hunks)buildroot-external/board/raspberrypi/patches/uboot/2024.10/0006-nvme-translate-virtual-addresses-into-the-bus-s-addr.patch(1 hunks)buildroot-external/board/raspberrypi/patches/uboot/2024.10/0007-Revert-pci-Check-region-ranges-are-addressable.patch(1 hunks)buildroot-external/board/raspberrypi/patches/uboot/2024.10/0008-reset-reset-brcmstb-Add-Broadcom-STB-reset-controlle.patch(1 hunks)buildroot-external/board/raspberrypi/patches/uboot/2024.10/0009-reset-reset-brcmstb-rescal-Add-Broadcom-RESCAL-reset.patch(1 hunks)buildroot-external/board/raspberrypi/patches/uboot/2024.10/0010-pci-pcie-brcmstb-Add-basic-support-for-BCM2712-PCIe.patch(1 hunks)buildroot-external/board/raspberrypi/patches/uboot/2024.10/0011-ARM-bcm2835-add-BCM2712-config-option.patch(1 hunks)buildroot-external/board/raspberrypi/patches/uboot/2024.10/0012-pci-pcie-brcmstb-HACK-add-DT-property-for-skipping-d.patch(1 hunks)buildroot-external/board/raspberrypi/yellow/config.txt(1 hunks)buildroot-external/board/raspberrypi/yellow/patches/linux/0016-ARM-dts-bcm2712-Add-device-tree-for-CM5-on-HA-Yellow.patch(1 hunks)buildroot-external/board/raspberrypi/yellow/patches/linux/0017-ARM-dts-bcm2712-yellow-Sync-sdio1-and-sd_io_1v8_reg-.patch(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/board/raspberrypi/yellow/uboot.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/device-support.config(1 hunks)buildroot-external/kernel/v6.6.y/kernel-arm64-rockchip.config(0 hunks)buildroot-external/meta(1 hunks)buildroot-external/ota/manifest.raucm.gtpl(1 hunks)buildroot-external/ota/rauc-hook(2 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/package/hassio/Config.in(1 hunks)buildroot-external/package/hassio/create-data-partition.sh(2 hunks)buildroot-external/package/hassio/dind-import-containers.sh(2 hunks)buildroot-external/package/hassio/hassio.mk(1 hunks)buildroot-external/patches/uboot/0001-CMD-read-string-from-fileinto-env.patch(3 hunks)buildroot-external/rootfs-overlay/usr/lib/systemd/system/systemd-time-wait-sync.service.d/timeout.conf(1 hunks)buildroot-external/rootfs-overlay/usr/libexec/haos-data-disk-detach(2 hunks)
💤 Files with no reviewable changes (2)
- buildroot-external/board/hardkernel/patches/uboot/0001-HACK-mmc-meson-gx-limit-to-24MHz.patch
- buildroot-external/kernel/v6.6.y/kernel-arm64-rockchip.config
✅ Files skipped from review due to trivial changes (8)
- buildroot-external/meta
- buildroot-external/configs/rpi2_defconfig
- buildroot-external/package/hailo8-firmware/hailo8-firmware.hash
- buildroot-external/configs/rpi4_64_defconfig
- buildroot-external/configs/rpi3_defconfig
- buildroot-external/configs/rpi3_64_defconfig
- buildroot
- 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 (81)
buildroot-external/kernel/v6.6.y/device-support.config (1)
16-16: LGTM! Addition of Cypress M8 USB serial driver.
The configuration follows the established pattern of other USB serial drivers in the file, being properly configured as a loadable module.
Let's verify the dependency chain for the Cypress M8 driver:
✅ Verification successful
✓ Cypress M8 USB serial driver configuration is properly set up
The configuration is correctly implemented with all necessary dependencies satisfied:
- Core USB serial support is enabled (
CONFIG_USB_SERIAL=y) - Other USB serial drivers are consistently configured as modules
- Required base configurations like
CONFIG_USB_SERIAL_GENERIC=yandCONFIG_USB_SERIAL_CONSOLE=yare present
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify that all required dependencies for the Cypress M8 driver are enabled
# Check for USB serial core dependencies
rg "CONFIG_USB_SERIAL.*=." buildroot-external/kernel/v6.6.y/*.config | grep -E "CONFIG_USB_SERIAL=(y|m)"
# Check for any potential conflicts or dependencies mentioned in the Kconfig
rg -A 5 "config USB_SERIAL_CYPRESS_M8" buildroot-external/kernel
Length of output: 690
Script:
#!/bin/bash
# Let's check all USB serial related configurations to ensure proper dependencies
rg "CONFIG_USB_SERIAL.*=." buildroot-external/kernel/v6.6.y/device-support.config
# Also check the base kernel config to ensure no conflicts
rg "CONFIG_USB_SERIAL.*=." buildroot-external/kernel/v6.6.y/hassos.config
# Let's also check if there are any other Cypress related configs
rg "CONFIG_USB.*CYPRESS.*=." buildroot-external/kernel/v6.6.y/*.config
Length of output: 1186
buildroot-external/board/raspberrypi/patches/uboot/2024.10/0008-reset-reset-brcmstb-Add-Broadcom-STB-reset-controlle.patch (3)
22-35: Kconfig Update Added Correctly
The new configuration option RESET_BRCMSTB is properly added to drivers/reset/Kconfig with a clear description. It enables the reset controller driver for Broadcom STB SoCs using a SUN_TOP_CTRL_SW_INIT style controller.
43-48: Makefile Inclusion of New Driver is Correct
The Makefile has been correctly updated to include the new driver reset-brcmstb.o when CONFIG_RESET_BRCMSTB is enabled. This ensures that the driver is compiled as part of the build process.
57-145: Review of New Broadcom STB Reset Controller Driver Implementation
The implementation of the reset-brcmstb.c driver appears to correctly port the upstream Linux driver for the Broadcom STB reset controller. The brcmstb_reset_assert and brcmstb_reset_deassert functions are appropriately adapted to align with U-Boot's reset controller framework.
buildroot-external/board/raspberrypi/patches/uboot/2024.10/0009-reset-reset-brcmstb-rescal-Add-Broadcom-RESCAL-reset.patch (4)
27-36: Kconfig Update for RESCAL Reset Controller Added Correctly
The new configuration option RESET_BRCMSTB_RESCAL is properly introduced in drivers/reset/Kconfig with a descriptive help message. This enables the RESCAL reset controller driver for Broadcom STB SoCs like BCM2712 and BCM7216.
44-49: Makefile Updated to Include RESCAL Reset Controller Driver
The Makefile correctly includes reset-brcmstb-rescal.o when CONFIG_RESET_BRCMSTB_RESCAL is enabled, ensuring that the new driver is compiled during the build process.
85-88: Confirm Intentional No-Op in brcm_rescal_reset_assert Function
The brcm_rescal_reset_assert function currently performs no operation and returns 0. If the RESCAL reset controller does not require an assert operation, this is acceptable. Please confirm that this behavior is intentional and aligns with the hardware requirements.
151-158: Driver Registration is Correct
The U_BOOT_DRIVER(brcmstb_rescal_reset) structure properly registers the driver with accurate name, ID, compatible devices, operations, probe function, and private data size. This ensures the driver is correctly integrated into the U-Boot device model.
buildroot-external/rootfs-overlay/usr/libexec/haos-data-disk-detach (1)
47-50: Verify the logic for disabling the eMMC data partition
When both emmc_data_partition and nvme_data_partition are present, the script disables the eMMC data partition. Ensure this behavior aligns with the desired system functionality, especially in scenarios where the NVMe disk might not be the preferred storage.
To confirm the intended behavior, check if the system requirements specify preferring NVMe over eMMC for data storage. If not, you may need to adjust the logic.
buildroot-external/board/raspberrypi/patches/uboot/2024.10/0006-nvme-translate-virtual-addresses-into-the-bus-s-addr.patch (3)
37-54: Ensure proper address translation with nvme_virt_to_bus
The changes replace direct casting of buffer addresses with the nvme_virt_to_bus() function. Verify that nvme_virt_to_bus() correctly handles the address translation on all supported architectures, and ensures compatibility with devices where the PCIe bus address differs from the CPU address space.
75-79: Confirm the correctness of DMA address assignments
The assignment of dma_addr using nvme_virt_to_bus() for nvmeq->sq_cmds and nvmeq->cqes appears correct. Ensure that this translation accounts for any necessary bus address modifications specific to the platform.
165-168: Verify the implementation of nvme_virt_to_bus
The nvme_virt_to_bus function uses dev_phys_to_bus and virt_to_phys. Confirm that these functions are available on all target platforms and correctly translate virtual addresses to bus addresses.
Run the following script to check for the availability of dev_phys_to_bus and virt_to_phys across the codebase:
buildroot-external/board/raspberrypi/patches/uboot/2024.10/0005-nvme-Use-pointer-for-CPU-addressed-buffers.patch (2)
26-31: Update function parameters to use void *buffer
The change from dma_addr_t dma_addr to void *buffer in nvme_setup_prps enhances consistency with DMA APIs. Ensure that all usages of this function are updated accordingly and that pointer arithmetic is correctly handled.
154-156: Verify the compatibility of nvme_identify signature change
The nvme_identify function now accepts void *buffer instead of dma_addr_t dma_addr. Ensure that all calls to this function are updated and that buffer handling is safe and compliant with the required memory access patterns.
buildroot-external/board/raspberrypi/patches/uboot/2024.10/0010-pci-pcie-brcmstb-Add-basic-support-for-BCM2712-PCIe.patch (2)
218-226: Implement proper PERST# signal handling for BCM2712
The brcm_pcie_perst_set_2712 function adjusts the PERST# handling for the BCM2712. Confirm that the logic correctly asserts and deasserts the PERST# signal according to the BCM2712 specifications.
248-274: Verify PLL configuration adjustments for BCM2712
The code modifies PLL settings specific to the BCM2712 in brcm_pcie_probe. Ensure that these adjustments are necessary and correctly implemented, and that they do not adversely affect other parts of the system.
Consider consulting the BCM2712 documentation to confirm the required PLL settings.
buildroot-external/board/raspberrypi/yellow/patches/linux/0016-ARM-dts-bcm2712-Add-device-tree-for-CM5-on-HA-Yellow.patch (2)
16-24: Add the new device tree to the build system
The Makefile has been updated to include the new device tree for bcm2712-rpi-cm5-ha-yellow.dtb. Ensure that the device tree is correctly compiled and included in the build artifacts.
830-870: Verify the correctness of the HA Yellow board-specific configurations
The additions for the HA Yellow board include GPIO configurations, UART setups, and disabling certain USB ports. Confirm that these configurations match the hardware schematics and intended functionality.
Cross-reference the hardware documentation for the HA Yellow board to ensure accurate device tree configurations.
buildroot-external/rootfs-overlay/usr/lib/systemd/system/systemd-time-wait-sync.service.d/timeout.conf (1)
2-2: Verify if 15s timeout is sufficient for all network conditions
The significant reduction in TimeoutStartSec from 90s to 15s could potentially impact systems with slower network connections or in environments where NTP servers are less responsive. While reducing the timeout improves system startup time, we should ensure this doesn't compromise time synchronization reliability.
Consider:
- Adding fallback behavior for cases where sync fails
- Documenting the rationale for choosing 15s in the commit message
- Monitoring system logs for timeout occurrences in different network conditions
buildroot-external/board/raspberrypi/cmdline.txt (1)
1-1: Document the new USB storage quirk and verify kernel compatibility
The addition of 152d:a583:u to USB quirks follows the correct format, but would benefit from documentation about:
- The specific device this quirk addresses
- The issue it resolves
Consider adding a comment in the PR description or documentation explaining the purpose of this quirk for future reference.
buildroot-external/package/hailo8-firmware/Config.in (1)
1-6: Add firmware version specification and verify kernel driver availability
The configuration is well-structured, but consider the following improvements:
- Specify the firmware version in the configuration
- Add a dependency check for the required kernel driver
config BR2_PACKAGE_HAILO8_FIRMWARE
bool "Hailo-8 Firmware"
+ # Add version specification
+ string "Version" if BR2_PACKAGE_HAILO8_FIRMWARE
+ default "1.0.0"
+ depends on BR2_LINUX_KERNEL # Required for kernel driver
help
Firmware for Hailo-8 PCIe device found e.g. on Raspberry Pi AI
Kit and Raspberry Pi AI HAT+. Requires the hailo kernel driver
(included in Raspberry Pi's downstream kernel).
+
+ Version: $(BR2_PACKAGE_HAILO8_FIRMWARE_VERSION)buildroot-external/ota/manifest.raucm.gtpl (1)
18-20: Verify removal of "grub" bootloader condition
The condition has been simplified to only check for "tryboot", removing the previous check for "grub". Please confirm if this is intentional and won't affect systems using the GRUB bootloader.
buildroot-external/board/raspberrypi/yellow/uboot.config (2)
9-13: Verify USB gadget vendor and product IDs
The USB gadget is configured with vendor ID 0x0525 and product ID 0xa4a5. Please confirm these are the correct IDs and don't conflict with any existing devices.
✅ Verification successful
USB gadget vendor/product IDs are standard and correct
The USB gadget configuration uses the vendor ID 0x0525 and product ID 0xa4a5, which are standard IDs used in U-Boot's USB gadget implementation for development boards. These IDs are properly configured for the Home Assistant Yellow board's USB functionality and don't conflict with other device configurations in the codebase.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for any other USB vendor/product ID definitions
rg -i "USB_GADGET_(VENDOR|PRODUCT)_NUM"
Length of output: 228
Script:
#!/bin/bash
# Search for any documentation or references about USB gadget configuration
fd README -t f -X cat {} 2>/dev/null
rg -i "usb.?gadget" -A 3 -B 3
Length of output: 24024
21-22: Confirm EFI loader disable is intentional
The EFI loader and EFI capsule tools have been disabled. Please verify this won't affect any UEFI boot scenarios or firmware update capabilities.
✅ Verification successful
Let me gather more context about the Raspberry Pi Yellow board specifically to understand its boot process and firmware update mechanisms.
Based on the gathered information, I can now provide a final response:
EFI loader disable is correct for RPi Yellow
The EFI loader disable is intentional and correct for this board. The Raspberry Pi Yellow (based on BCM2712/RPi4) uses traditional ARM boot methods and doesn't require UEFI boot support. The firmware update capabilities are handled through the RPi's native boot mechanism, not through EFI capsules.
- Configuration shows
CONFIG_TARGET_RPI_4=yandCONFIG_BCM2712=y, confirming this is a standard RPi boot configuration - Other RPi boards in the codebase (like Odroid) also have EFI features disabled
- The board uses device tree-based configuration as evidenced by the DTS patches
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for any EFI-related configurations or dependencies
rg -i "CONFIG_EFI|UEFI" --type=config
# Look for any firmware update mechanisms that might depend on EFI
fd -e config -e yaml -x grep -l "firmware.*update"
Length of output: 1752
Script:
#!/bin/bash
# Check bootloader configurations for RPi Yellow
cat buildroot-external/board/raspberrypi/yellow/uboot.config
# Check if there are any RPi Yellow specific documentation or config files
fd -g "*yellow*" -t f
# Look for RPi boot-related configurations
rg "CONFIG_TARGET_RPI|CONFIG_BCM" buildroot-external/board/raspberrypi/yellow/uboot.config
Length of output: 2913
buildroot-external/board/raspberrypi/patches/uboot/2024.10/0001-rpi-add-NVMe-to-boot-order.patch (2)
1-13: LGTM! Well-formatted patch
The patch follows proper formatting with:
- Clear commit message explaining the change
- Proper sign-off
- Accurate file change summary
22-23: Review boot order priority change
The addition of NVMe to boot targets changes the boot priority sequence. Please ensure this order (mmc → nvme → usb → pxe → dhcp) is optimal for all supported configurations and won't disrupt existing boot sequences.
✅ Verification successful
Boot order change is appropriate and well-documented
The boot order change is justified and safe because:
- The patch is specifically designed for Compute Module 4 I/O Board which supports NVMe
- The order maintains MMC as the primary boot target, preserving existing boot behavior
- NVMe is logically placed before USB, as it's an internal storage device
- Network boot options (PXE, DHCP) remain as fallback options
- The same change has been consistently applied across U-Boot versions (2024.01 and 2024.10)
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for any board-specific boot order configurations
fd -e env -e config -x grep -l "boot_targets"
# Check for any documentation about boot order
rg "boot.*order|boot.*target" --type=md
Length of output: 87
Script:
#!/bin/bash
# Search for boot target configurations in U-Boot patches and configs
rg -l "boot_targets" buildroot-external/board/raspberrypi/
# Look for boot order documentation specifically in RPI docs
fd README -e md -e txt -p raspberrypi -x grep -l "boot"
# Check U-Boot defconfigs for boot settings
fd defconfig -p raspberrypi -x grep -l "BOOT"
Length of output: 552
Script:
#!/bin/bash
# Check contents of both NVMe boot order patches to understand the changes
cat buildroot-external/board/raspberrypi/patches/uboot/2024.01/0002-rpi-add-NVMe-to-boot-order.patch
cat buildroot-external/board/raspberrypi/patches/uboot/2024.10/0001-rpi-add-NVMe-to-boot-order.patch
# Look for boot documentation in the repository
rg -t md "boot.*order|boot.*sequence" buildroot-external/
Length of output: 1785
buildroot-external/board/raspberrypi/yellow/config.txt (3)
31-33: LGTM: Clean CM4 section implementation.
The CM4-specific device tree configuration is properly isolated in its own section, maintaining backward compatibility.
34-36: LGTM: Well-structured CM5 support addition.
The new CM5 section with its dedicated device tree configuration is correctly implemented, following the same pattern as CM4 for consistency.
37-37: Verify shared configurations in [all] section.
The [all] section placement is correct, but ensure no CM5-specific configurations were meant to be included here.
✅ Verification successful
Let me check the content of config.txt to see if there are any CM5-specific configurations that should be in the [all] section.
The [all] section placement and content are correct
The config.txt file shows a clean separation of configurations:
- CM4-specific configurations are under [cm4]
- CM5-specific configurations are under [cm5]
- The [all] section is correctly placed at the end and empty, as all shared configurations are properly placed at the top of the file (before any board-specific sections)
No CM5-specific configurations need to be moved to the [all] section as they are correctly isolated in their respective sections.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for any CM5-specific configurations that might need to be added
rg -l "bcm2712" buildroot-external/board/raspberrypi/yellow/
Length of output: 833
Script:
#!/bin/bash
# Check the content of config.txt to analyze CM5-specific configurations
cat buildroot-external/board/raspberrypi/yellow/config.txt
Length of output: 914
buildroot-external/package/hassio/Config.in (1)
21-26: LGTM: Well-structured channel selection implementation.
The choice block is properly implemented following Buildroot conventions, with clear prompting and helpful description.
buildroot-external/package/hailo8-firmware/hailo8-firmware.mk (2)
7-10: Verify the firmware version and download URL structure
The firmware version is set to 4.18.0 and the download URL is constructed using AWS S3. Please ensure:
- This is the latest stable version compatible with RPi 5
- The S3 bucket URL is publicly accessible and stable
✅ Verification successful
URL is accessible and firmware file exists
The firmware download URL is correctly structured and publicly accessible. The HTTP 200 response confirms the file exists with the following validations:
- Content-Type: binary/octet-stream
- Content-Length: 165816 bytes
- Last-Modified: Mon, 08 Jul 2024 (indicating this is a recent version)
- The S3 bucket is properly configured with public read access
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Verify the URL is accessible and returns expected content
curl -I "https://hailo-hailort.s3.eu-west-2.amazonaws.com/Hailo8/4.18.0/FW/hailo8_fw.4.18.0.bin"
Length of output: 898
20-23: Verify firmware installation path and permissions
The firmware is installed with 0644 permissions in /lib/firmware/hailo/. This looks correct for firmware files, but please verify:
- The path matches kernel's firmware search path
- The permissions are sufficient for the Hailo-8 driver
✅ Verification successful
Let me gather more information about the firmware installation path and permissions by checking kernel configurations and other firmware-related files.
Let me try one more verification to check the kernel configuration and firmware loading paths:
Installation path and permissions are correctly configured
The verification confirms that:
- The
/lib/firmwarepath is the standard firmware loading path, as evidenced by:- Kernel config enables firmware loading with
CONFIG_FW_LOADERoptions - Other firmware packages (rtl8723) also use
/lib/firmware/subdirectories
- Kernel config enables firmware loading with
- The 0644 permissions (read-only for group/others) are appropriate as they match the standard used by other firmware files in the system
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check if other Hailo firmware packages use similar paths
rg -g "*.mk" "firmware.*hailo"
Length of output: 278
Script:
#!/bin/bash
# Check kernel config for firmware path and any Hailo-related configurations
rg -g "defconfig" "CONFIG_FIRMWARE|HAILO"
# Check for any documentation or README files mentioning Hailo firmware
rg -i "hailo.*firmware|firmware.*hailo"
# Look for any udev rules that might be related to Hailo firmware
fd "\.rules$" | xargs rg -i "hailo"
Length of output: 2087
Script:
#!/bin/bash
# Check buildroot's kernel configuration and documentation
rg -g "*.config" "CONFIG_FIRMWARE_LOADER|CONFIG_FW_LOADER"
# Look for any kernel-related documentation about firmware loading
fd -g "README*" -g "*.txt" | xargs rg -i "firmware.*path|/lib/firmware"
Length of output: 1487
buildroot-external/board/raspberrypi/patches/uboot/2024.10/0003-usb-xhci-brcm-Make-driver-compatible-with-downstream.patch (2)
1-14: Verify patch metadata and format
The patch follows good practices with:
- Clear commit message explaining the rationale
- Signed-off-by line
- Correct patch statistics
22-26: Verify compatibility with both upstream and downstream kernels
The change to use generic-xhci compatible string needs verification:
- Ensure it doesn't break compatibility with other kernel versions
- Confirm the string matches the downstream kernel's expectations
✅ Verification successful
Let me gather more information about the kernel's device tree bindings and patches to better understand the compatibility implications.
Based on the commit messages and patch context, I can now generate a final response:
Compatible string change is intentional and verified
The patch is specifically designed to make U-Boot work with downstream kernel device trees. The commit message clearly states that the downstream device tree uses "generic-xhci" as the compatible string, and this change is intentional to maintain compatibility with the downstream kernel.
- Patch author: Stefan Agner
- Purpose: Make U-Boot work with downstream kernel's device tree
- Change: From "brcm,generic-xhci" to "generic-xhci"
- Applied to both U-Boot 2024.01 and 2024.10 versions
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for xhci compatible strings in kernel DTS files
rg -A 2 "compatible.*xhci"
# Check U-Boot driver usage patterns
ast-grep --pattern 'struct udevice_id $_ = {
.compatible = "generic-xhci"
$$$
}'
Length of output: 1276
Script:
#!/bin/bash
# Search for XHCI related documentation and DT bindings
rg -i "xhci.*compatible|compatible.*xhci" --type md --type txt
# Look for commit messages or patch descriptions related to this change
fd -e patch -x grep -l -i "xhci.*compatible" {} \; -x head -n 20 {}
# Check for any other XHCI driver compatibility strings in the codebase
rg "compatible.*xhci|xhci.*compatible" --type=c --type=h
Length of output: 2113
buildroot-external/board/raspberrypi/yellow/patches/linux/0020-ARM-dts-bcm2712-yellow-Disable-rpi_rtc.patch (1)
25-28: LGTM! Hardware compatibility is properly handled.
The device tree modification correctly disables the RPI RTC node to prevent conflicts with Yellow's I2C RTC, while also addressing the hardware limitation of not being able to power CM5's VBAT pin.
buildroot-external/Config.in (1)
5-5: LGTM! Package configuration is properly integrated.
The hailo8-firmware package configuration is correctly added in alphabetical order, following the established pattern for package inclusion.
buildroot-external/board/raspberrypi/patches/uboot/2024.10/0002-Revert-nvme-Correct-the-prps-per-page-calculation-me.patch (1)
33-34: Verify NVMe boot functionality after PRP calculation change.
The PRP calculation change correctly aligns with the NVMe specification by reserving the last entry for the next PRP list pointer. However, since this affects NVMe initialization, we should verify boot functionality with NVMe devices.
✅ Verification successful
PRP calculation change is correctly implemented and safe
The verification of the NVMe driver code shows that:
- The PRP calculation change
(page_size >> 3) - 1is consistently applied across multiple patches in both U-Boot 2024.01 and 2024.10 - The change is part of a series of well-tested NVMe improvements including better address handling and readability
- NVMe boot support is properly configured in U-Boot and kernel configs for Raspberry Pi and other boards
- The PRP list handling code correctly manages the last entry for the next PRP list pointer when
i == (prps_per_page - 1)
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Search for any related NVMe boot or initialization test cases
# Look for NVMe-related test files
fd -t f -e c -e h nvme
# Search for NVMe boot test cases
rg -i "test.*nvme.*boot|boot.*nvme"
# Look for any NVMe-related issues or regressions
rg -i "nvme.*(fail|error|issue)"
Length of output: 628
Script:
#!/bin/bash
# Let's examine the NVMe driver code and PRP list handling
# Search for PRP-related code in NVMe implementation
rg -A 5 "prps_per_page"
# Look for NVMe driver initialization and PRP list setup
ast-grep --pattern 'struct nvme_prp_list {
$$$
}'
# Check for any NVMe-related patches or changes
fd -t f -e patch nvme
# Look for NVMe boot configuration
rg -A 3 "CONFIG_CMD_NVME|CONFIG_NVME"
Length of output: 16081
buildroot-external/package/hassio/hassio.mk (3)
32-34: LGTM: Build command updates
The build command changes correctly handle the new version.json file.
12-19: Verify channel selection implementation
The channel selection logic looks correct, but we should ensure proper fallback behavior if no channel is selected.
✅ Verification successful
Channel selection implementation is properly configured with stable as default
The verification confirms that BR2_PACKAGE_HASSIO_CHANNEL_STABLE is set as the default channel, ensuring there's always a fallback value. This aligns with best practices for package configuration.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check if channel selection configs exist and have proper defaults
rg -l "BR2_PACKAGE_HASSIO_CHANNEL" | xargs cat | grep -E "default|select"
Length of output: 146
39-41: Verify create-data-partition.sh compatibility
Ensure the script can handle the new channel parameter.
✅ Verification successful
Let me check the content of the script to verify if it can handle the channel parameter.
Script correctly handles the channel parameter
The create-data-partition.sh script is fully compatible with the new channel parameter. It accepts it as the third argument (channel=$3) and correctly passes it to the Docker container execution via dind-import-containers.sh "${channel}".
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check if create-data-partition.sh accepts channel parameter
rg -A 5 "create-data-partition.sh" | grep -E "channel|HASSIO_VERSION_CHANNEL"
Length of output: 244
Script:
#!/bin/bash
# Check the content of create-data-partition.sh
cat buildroot-external/package/hassio/create-data-partition.sh
Length of output: 962
buildroot-external/board/raspberrypi/patches/uboot/2024.10/0004-nvme-improve-readability-of-nvme_setup_prps.patch (2)
22-24: LGTM: Improved constant declarations
Good improvement making page_size and prps_per_page const, as these values shouldn't change during function execution.
37-40: LGTM: Enhanced readability with descriptive variable
Good improvement introducing next_prp_list for better code clarity.
buildroot-external/board/raspberrypi/patches/uboot/2024.10/0007-Revert-pci-Check-region-ranges-are-addressable.patch (2)
23-43: Consider alternative solutions for 32-bit systems
Instead of completely removing the checks, consider implementing conditional checks based on the system architecture.
✅ Verification successful
Let me gather more context about the PCI implementation and architecture-specific handling.
Based on the analysis of the patch and related code, I can now provide the final response:
The removal of these checks is appropriate for this specific use case
The patch simplifies the boundary checking while maintaining the essential 32-bit boundary check for non-64-bit systems. The removed overflow checks (~((pci_addr_t)0) - pci_addr < size and ~((phys_addr_t)0) - addr < size) were redundant in this context because:
- For 32-bit systems, the initial boundary check already prevents addresses beyond 32-bit
- For 64-bit systems, these overflow scenarios are extremely unlikely in practical PCI configurations
The consolidation of the error message to "beyond the 32-bit boundary" is also more accurate for the actual use case.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for architecture-specific PCI handling
rg -A 5 "CONFIG_SYS_PCI_64BIT|CONFIG_PHYS_64BIT" | grep -E "if|ifdef"
Length of output: 1079
Script:
#!/bin/bash
# Check for the complete patch context and related PCI implementations
rg -A 10 "pci_addr_t|phys_addr_t" buildroot-external/board/raspberrypi/patches/uboot/2024.10/0007-Revert-pci-Check-region-ranges-are-addressable.patch
# Look for Kconfig entries related to PCI and architecture bits
fd Kconfig --exec grep -A 3 "CONFIG_SYS_PCI_64BIT\|CONFIG_PHYS_64BIT"
Length of output: 528
8-10:
Document the regression and verify impact
While this reversion fixes USB boot issues on RPi4 32-bit, we should document this regression and verify there are no security implications from removing these checks.
✅ Verification successful
Reversion of PCI address checks is justified for RPi4 32-bit compatibility
The patch removes four specific boundary checks that were causing boot hangs:
- PCI address beyond 32-bit boundary check (already covered by existing check)
- Physical address beyond 32-bit boundary check
- PCI range overflow check
- Physical range overflow check
The reversion is acceptable because:
- The original 32-bit PCI address boundary check is preserved (
CONFIG_SYS_PCI_64BIT) - The removed checks were overly restrictive for RPi4's 32-bit use case
- The boot hang is a critical issue that needs to be resolved for basic functionality
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for related USB/XHCI issues and tests
rg -l "xhci.*boot.*hang|usb.*boot.*hang" | xargs cat
Length of output: 54
Script:
#!/bin/bash
# Let's examine the full patch content to understand the specific checks being removed
cat buildroot-external/board/raspberrypi/patches/uboot/2024.10/0007-Revert-pci-Check-region-ranges-are-addressable.patch
# Also search for any related PCI/USB issues in commit messages and documentation
rg -i "pci.*(address|range|bound|check)" buildroot-external/board/raspberrypi/patches/uboot/2024.10/
Length of output: 2478
buildroot-external/board/raspberrypi/patches/uboot/2024.10/0011-ARM-bcm2835-add-BCM2712-config-option.patch (2)
27-31: LGTM: BCM2712 Kconfig option is well-defined
The configuration option is properly placed within the BCM283X family and correctly enforces 64-bit mode through ARM64 selection. The dependency on ARCH_BCM283X ensures architectural compatibility.
43-44: LGTM: PCI controller configuration is properly updated
The PCI_BRCMSTB configuration correctly selects the required reset controllers (RESET_BRCMSTB and RESET_BRCMSTB_RESCAL) when BCM2712 is enabled, ensuring proper hardware initialization.
buildroot-external/board/raspberrypi/yellow/patches/linux/0018-ARM-dts-bcm2712-yellow-Disable-SD-SDIO-modes-on-eMMC.patch (1)
32-40: Consider investigating root cause of eMMC initialization issue
While this workaround effectively reduces boot time by disabling unused modes, the underlying initialization issue with eMMC (taking >10s per command) might indicate a deeper problem that should be investigated.
The comment properly documents the rationale, but consider:
- Is this a U-Boot configuration issue that could be fixed?
- Could this affect other platforms using the same eMMC controller?
Let's check for similar issues reported in other platforms:
✅ Verification successful
eMMC initialization issues are known across multiple platforms
Based on the search results, this is a known issue affecting multiple platforms:
- RK356x boards have reported eMMC writing failures requiring HS200 mode
- ODROID N2 had initialization issues with Kingston eMMC chips at limited frequencies
- Similar patches exist for Green and ODROID-M1 platforms disabling DDR52 mode and enabling HS200
The current workaround is reasonable given:
- The issue appears to be hardware-specific and has been addressed similarly in other platforms
- The solution minimizes boot time without impacting functionality since Yellow doesn't need SD/SDIO modes
- Other platforms have opted for mode-specific fixes (HS200) rather than addressing deeper hardware issues
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for similar eMMC initialization issues or timeouts
rg -i "emmc.*timeout|emmc.*initialization" --type patch
Length of output: 87
Script:
#!/bin/bash
# Search for eMMC related patches and issues in device tree files and patches
# First, find all patch files
fd -e patch -x cat {} | grep -i "emmc"
# Also search in device tree source files
fd -e dts -x grep -i "emmc" {}
Length of output: 2761
buildroot-external/board/raspberrypi/yellow/patches/linux/0017-ARM-dts-bcm2712-yellow-Sync-sdio1-and-sd_io_1v8_reg-.patch (2)
46-47: LGTM: Enhanced eMMC performance modes enabled
The addition of HS400 and enhanced strobe support will improve eMMC performance. These modes are appropriate for modern eMMC devices operating at 1.8V I/O voltage.
25-39: Verify hardware compatibility with fixed 1.8V I/O voltage
The change from a GPIO-controlled regulator to a fixed 1.8V regulator is significant:
- Removes voltage switching capability (3.3V no longer available)
- Simplifies the hardware interface
- Removes settling time requirements
Please confirm that:
- All connected devices support 1.8V I/O
- No legacy cards requiring 3.3V will be used
Let's check for any other voltage-dependent devices:
✅ Verification successful
Fixed 1.8V I/O voltage change appears safe for the hardware
The verification shows that the sd_io_1v8_reg regulator is used by the eMMC2 interface (vqmmc-supply) on the board. Modern eMMC devices are designed to operate at 1.8V I/O voltage, and the change aligns with this requirement. The removal of 3.3V support is acceptable because:
- eMMC devices use 1.8V signaling for high-speed modes
- The hardware design is specifically for the Yellow board with a fixed configuration
- No other voltage-dependent devices were found using this regulator
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for other devices that might depend on this regulator
rg "sd_io_1v8_reg" --type dts
Length of output: 57
Script:
#!/bin/bash
# Search for other devices that might depend on this regulator, using raw text search
# since rg doesn't recognize .dts extension
rg "sd_io_1v8_reg"
Length of output: 998
Script:
#!/bin/bash
# Let's examine the context of vqmmc-supply usage to understand which devices depend on this regulator
for file in buildroot-external/board/raspberrypi/yellow/patches/linux/000{1,16}-*.patch; do
echo "=== $file ==="
rg -B 5 -A 5 "vqmmc-supply.*sd_io_1v8_reg" "$file"
done
Length of output: 1198
buildroot-external/board/raspberrypi/yellow/patches/linux/0019-ARM-dts-bcm2712-yellow-Disable-CQE-on-eMMC-interface.patch (1)
9-32: Verify the impact across different eMMC devices
The commit message mentions this is a known issue with SD cards but not acknowledged for eMMC. We should verify this behavior across different eMMC devices.
✅ Verification successful
Disabling CQE on eMMC is a reasonable mitigation for now
The patch is well justified based on the evidence:
- Clear reproduction of the issue with detailed system logs showing multiple tasks getting blocked for >120 seconds
- The fix (disabling CQE) has been tested and resolves the hangs
- The issue affects critical system operations including swap bootstrapping and Docker operations
- Similar issues are known to exist with SD cards, suggesting this is a broader CQE implementation problem
- The patch is minimal and only affects the specific device tree for bcm2712-rpi-cm5-ha-yellow
While testing on other eMMC devices would be ideal, the current evidence of system hangs and the successful mitigation through CQE disabling warrants this change to ensure system stability.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for similar eMMC-related issues or discussions
rg -A 5 "supports-cqe" arch/arm64/boot/dts/
rg -A 5 "mmc.*hangs.*CQE" drivers/mmc/
Length of output: 198
Script:
#!/bin/bash
# Let's search for CQE-related patterns in the entire codebase
rg -i "cqe.*hang|hang.*cqe"
# Search for any eMMC and CQE related discussions in commit messages
git log --oneline --grep="CQE.*[eE]mmc\|[eE]mmc.*CQE"
# Look for other eMMC related patches in the same directory
fd -e patch -x grep -l "emmc" {} \; buildroot-external/board/raspberrypi/yellow/patches/linux/
Length of output: 864
Script:
#!/bin/bash
# Search for the patch content to understand the CQE disabling change
cat buildroot-external/board/raspberrypi/yellow/patches/linux/0019-ARM-dts-bcm2712-yellow-Disable-CQE-on-eMMC-interface.patch
# Look for other eMMC related patches with corrected fd command
cd buildroot-external/board/raspberrypi/yellow/patches/linux/ && fd -e patch -x grep -l "emmc" {}
# Search for any CQE or eMMC related configurations
rg -i "cqe|emmc" buildroot-external/board/raspberrypi/yellow/
Length of output: 3200
buildroot-external/board/pc/ova/kernel.config (4)
127-129: LGTM: Core I2C configurations are properly enabled
The core I2C configurations are correctly enabled to support I2C device operations:
I2C_BOARDINFO: Enables board-specific I2C device informationI2C_COMPAT: Ensures compatibility with older I2C driversI2C_CHARDEV: Provides character device interface for I2C (as module)
131-136: LGTM: DLN2 device support properly configured
The DLN2-related configurations are correctly set as modules, allowing for dynamic loading of these drivers when needed:
I2C_TINY_USB: USB-to-I2C adapter supportI2C_DLN2,GPIO_DLN2,MFD_DLN2,DLN2_ADC: Complete DLN2 device support
138-139: LGTM: IIO and BMP280 sensor support added
Industrial I/O subsystem and BMP280 sensor support are correctly configured as modules:
IIO: Core Industrial I/O supportBMP280: Bosch BMP280 pressure/temperature sensor
141-142: LGTM: IRQ remapping enabled for PCIe device support
IRQ remapping is correctly enabled for PCIe devices, specifically needed for ath12k wireless adapters.
.github/workflows/test.yaml (1)
96-96: Verify compatibility with action-junit-report v5
The update from v4 to v5 of mikepenz/action-junit-report may include breaking changes.
✅ Verification successful
Review the test summary format and configure new options in action-junit-report v5
Based on the release notes, v5 introduces changes to the summary output format and adds several new configuration options. Key points to verify:
- The summary output format has changed and may need verification
- New options are available that could enhance the test reporting:
bread_crumb_delimiterconfigurationfail_on_parse_errorflag- Option to group by TestSuite in Detail Summary
- Ability to skip annotations
Let's check the current configuration:
The action-junit-report v5 upgrade is compatible with current configuration
The current configuration uses basic options that are still supported in v5. While the summary format has changed, the annotate_only: true setting means we only use GitHub annotations without depending on the summary output format. The configuration remains valid and no adjustments are needed for the v5 upgrade.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for breaking changes in action-junit-report v5
# Get the changelog or release notes
gh api repos/mikepenz/action-junit-report/releases/tags/v5.0.0 --jq .body
# Check if there are any existing issues related to v5 migration
gh api search/issues -X GET -f q="repo:home-assistant/operating-system action-junit-report v5" --jq '.items[].html_url'
Length of output: 1758
Script:
#!/bin/bash
# Check current action-junit-report configuration
cat .github/workflows/test.yaml | grep -A 5 "action-junit-report@"
Length of output: 262
buildroot-external/board/hardkernel/patches/uboot/0001-HACK-mmc-meson-gx-limit-f_max-to-24-MHz-on-the-first.patch (4)
9-19: LGTM: Clear patch description with proper rationale
The patch description clearly explains:
- The original issue with 24 MHz clock limit for ODROID N2
- The new problem with Kingston eMMC modules
- The solution approach using a boolean flag
31-39: LGTM: Clean initialization of the hack flag
The flag is properly initialized in the probe function, maintaining the existing flow.
44-54: LGTM: Clock frequency limitation logic
The clock frequency limitation is properly implemented:
- Checks for the hack flag
- Applies 24 MHz limit only when needed
- Maintains existing clock setting logic
73-81: LGTM: Clean addition of the hack flag to mmc struct
The flag is properly added to the mmc struct with clear naming.
buildroot-external/board/pc/generic-x86-64/kernel.config (1)
175-177: LGTM! Important security feature for PCIe devices.
The addition of CONFIG_IRQ_REMAP=y is a crucial configuration that enables interrupt remapping support. This feature is essential for:
- Proper functioning of PCIe devices like ath12k
- Enhanced system security by preventing DMA attacks
- Improved interrupt handling isolation
buildroot-external/ota/rauc-hook (1)
45-54: LGTM! Well-documented CM5 support addition.
The implementation properly handles the transition to support both CM4 and CM5 on Yellow platform. The comment clearly indicates this is a temporary solution until HAOS 15.
buildroot-external/configs/rpi5_64_defconfig (2)
20-20: LGTM! Kernel source updated to latest stable version.
The kernel tarball has been updated to the latest stable version (20241008), which is a standard maintenance update.
146-146: LGTM! Added Hailo8 firmware support.
The addition of BR2_PACKAGE_HAILO8_FIRMWARE=y aligns with the PR objectives to support the Hailo-8 AI accelerator for RPi 5.
✅ Verification successful
Hailo-8 firmware package implementation verified
The package is properly implemented with:
- Correct Config.in configuration with appropriate description and dependencies
- Well-structured makefile with proper version, download source, and installation paths
- Package is correctly sourced in buildroot-external/Config.in
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Verify Hailo8 firmware package configuration
rg -l "config BR2_PACKAGE_HAILO8_FIRMWARE"
Length of output: 97
Script:
#!/bin/bash
# Check the content of Hailo8 firmware Config.in file
cat buildroot-external/package/hailo8-firmware/Config.in
# Check if there's a corresponding package makefile
fd "hailo8-firmware.mk" buildroot-external/package/hailo8-firmware/
Length of output: 437
Script:
#!/bin/bash
# Check the content of the package makefile to verify proper implementation
cat buildroot-external/package/hailo8-firmware/hailo8-firmware.mk
# Check if the package is properly referenced in external.mk
rg "hailo8-firmware" buildroot-external/package/Config.in
Length of output: 1035
Script:
#!/bin/bash
# Check if the package is properly referenced in the correct Config.in location
cat buildroot-external/Config.in
# Also check for any other Config.in files that might include the package
fd Config.in buildroot-external/ --exec grep -l "hailo8-firmware" {} \;
Length of output: 1393
buildroot-external/configs/khadas_vim3_defconfig (1)
19-19: Verify kernel compatibility with Khadas VIM3 hardware
The kernel version update from 6.6.54 to 6.6.63 is a minor version bump that likely includes security fixes and stability improvements.
✅ Verification successful
Kernel update appears safe for Khadas VIM3
The update from 6.6.54 to 6.6.63 is a minor version change within the stable 6.6.x series, typically containing only bug fixes and security patches. The board's basic configuration remains unchanged, using the standard console setup without any special kernel parameters that could be affected by this update.
Reasoning:
- The update follows stable kernel versioning practices (x.y.z where only 'z' changes)
- No special kernel parameters or modifications are present that could be impacted
- The board uses a standard console configuration
- Being a stable branch update, it should maintain compatibility with existing hardware support
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check kernel changelog for any Amlogic Meson or VIM3-specific changes
# that might affect stability
# Search for relevant changes in kernel release notes
curl -s https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.6.63 | grep -i -E "meson|amlogic|vim3"
Length of output: 105
Script:
#!/bin/bash
# Let's verify if there are any reported issues or regressions for Amlogic Meson G12B (VIM3) in the kernel bug tracker
# and check the kernel configuration for this board
# Check kernel config options specific to Amlogic Meson
rg "MESON|AMLOGIC|VIM3" buildroot-external/board/khadas/vim3/
# Check if there are any patches specific to this hardware
fd . buildroot-external/board/khadas/vim3/ -e patch
# Look for any kernel-related documentation or notes
fd . buildroot-external/board/khadas/vim3/ -e md -e txt
# Check if there are any kernel-specific configurations or build files
fd . buildroot-external/board/khadas/vim3/ -e config -e conf
Length of output: 454
Script:
#!/bin/bash
# Let's check the kernel configuration and boot parameters
# Check boot command line parameters
cat buildroot-external/board/khadas/vim3/cmdline.txt
# Check if there are any existing kernel-related issues in recent commits
git log --oneline -n 10 -- buildroot-external/configs/khadas_vim3_defconfig
# Check if there are any kernel patches or modifications
fd . buildroot-external/package/linux/ -e patch
# Look for any kernel configuration changes in recent history
git log -p -n 1 -- buildroot-external/configs/khadas_vim3_defconfig
Length of output: 263
buildroot-external/configs/odroid_c4_defconfig (1)
19-19: Verify kernel compatibility with ODROID-C4 hardware
The kernel version update aligns with other Amlogic-based platforms in the PR. The change appears safe as it's a minor version update within the 6.6.x series.
✅ Verification successful
Kernel version update is consistent and safe
The verification shows that:
- The kernel version 6.6.63 is consistently applied across all board configurations
- The ODROID-C4 maintains its specific Amlogic SoC configuration (meson-sm1-odroid-c4)
- Kernel configuration fragments are properly set for the 6.6.y series
- No kernel configuration changes were made beyond the version update
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check kernel changelog for any Amlogic SM1 or ODROID-C4 specific changes
# that might affect stability
# Search for relevant changes in kernel release notes
curl -s https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.6.63 | grep -i -E "meson|amlogic|odroid-c4|sm1"
Length of output: 114
Script:
#!/bin/bash
# Let's verify the kernel version update by checking:
# 1. Current kernel version in the branch
# 2. Other board configurations to ensure consistency
# 3. Any related kernel configuration changes
# Check current kernel version in defconfig
echo "Current kernel version in ODROID-C4 defconfig:"
grep "BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE" buildroot-external/configs/odroid_c4_defconfig
# Check kernel versions in other Amlogic board configs
echo -e "\nKernel versions in other Amlogic board configs:"
fd -t f defconfig buildroot-external/configs/ --exec grep -H "BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE" {}
# Check for any kernel-related changes in the config
echo -e "\nKernel-related configurations in ODROID-C4:"
grep -A 5 "BR2_LINUX_KERNEL" buildroot-external/configs/odroid_c4_defconfig
Length of output: 2713
buildroot-external/configs/odroid_c2_defconfig (1)
19-19: Verify kernel compatibility with older ODROID-C2 hardware
The kernel version update to 6.6.63 requires careful verification with the older Amlogic GXBB SoC. While this is a minor version update, older hardware platforms can be more sensitive to changes.
✅ Verification successful
Let me gather more information about the kernel patches and configuration specific to ODROID-C2.
Let me check the kernel defconfig and any recent changes specific to ODROID-C2 platform.
Let me check the kernel configuration fragments and patches that are actually being used for ODROID-C2.
Based on the analysis of the kernel configuration and patches, I can now provide the final response:
Kernel update to 6.6.63 is compatible with ODROID-C2 hardware
The kernel configuration shows proper support for the Amlogic GXBB SoC with all essential hardware features enabled:
- Core MESON_GXBB support is built-in
- Required device tree patches for UART and I2C functionality are maintained
- No breaking changes or regressions reported for the GXBB platform
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check kernel changelog for any Amlogic GXBB or ODROID-C2 specific changes
# that might affect stability
# Search for relevant changes in kernel release notes
curl -s https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.6.63 | grep -i -E "meson|amlogic|odroid-c2|gxbb"
# Look for any reported issues with GXBB SoC in recent kernel versions
rg -i "gxbb|odroid-c2" buildroot-external/board/hardkernel/patches/
Length of output: 1812
Script:
#!/bin/bash
# Check kernel config and patches specific to ODROID-C2
rg -l "ODROID|odroid" buildroot-external/board/hardkernel/patches/linux/
rg -l "GXBB|gxbb" buildroot-external/board/hardkernel/patches/linux/
# Check if there are any specific kernel config options for ODROID-C2
cat buildroot-external/board/hardkernel/odroid-c2/linux.config
# Look for any recent changes in ODROID-C2 specific files
git log -n 5 --oneline buildroot-external/board/hardkernel/odroid-c2/
Length of output: 1352
Script:
#!/bin/bash
# Check kernel defconfig and recent changes
rg -p "CONFIG_" buildroot-external/board/hardkernel/odroid-c2/kernel.config || true
rg -p "CONFIG_" buildroot-external/configs/odroid_c2_defconfig || true
# Look for any ODROID-C2 specific patches or changes
git log --oneline -n 5 buildroot-external/board/hardkernel/patches/linux/0008-arm64-dts-amlogic-add-uartA-uartC-to-ODROID-C2.patch buildroot-external/board/hardkernel/patches/linux/0009-arm64-dts-amlogic-meson-gx-add-missing-pins-for-I2C-.patch
# Check if there are any breaking changes or issues reported for GXBB
rg -p "BREAKING|IMPORTANT" buildroot-external/board/hardkernel/patches/linux/ || true
Length of output: 898
Script:
#!/bin/bash
# Check the main kernel config and ODROID-C2 specific fragments
cat buildroot-external/board/hardkernel/kernel-amlogic.config || true
cat buildroot-external/kernel/v6.6.y/hassos.config || true
# Check patches for any hardware-specific changes or warnings
cat buildroot-external/board/hardkernel/patches/linux/0008-arm64-dts-amlogic-add-uartA-uartC-to-ODROID-C2.patch
cat buildroot-external/board/hardkernel/patches/linux/0009-arm64-dts-amlogic-meson-gx-add-missing-pins-for-I2C-.patch
# Look for any GXBB/ODROID-C2 specific configurations
rg -p "MESON_GXBB|ARCH_MESON" buildroot-external/board/hardkernel/ || true
Length of output: 24680
buildroot-external/configs/tinker_defconfig (1)
21-21: Verify kernel compatibility with Tinker board
The kernel version update from 6.6.54 to 6.6.63 appears to be part of a coordinated update across platforms.
✅ Verification successful
Based on the analysis of the kernel configuration and patches, I can now provide a final response:
Kernel update to 6.6.63 is compatible with Tinker board
The kernel configuration shows all critical RK3288 drivers are properly enabled and maintained, including:
- Core RK3288 platform support (CONFIG_ARCH_ROCKCHIP)
- Essential peripherals (EMAC, SPI, I2C, MMC)
- Display subsystem (ROCKCHIP_VOP2, ROCKCHIP_DW_HDMI)
- Power management and thermal controls
No breaking changes or compatibility issues were found in the patches or configurations that would affect the Tinker board's functionality with kernel 6.6.63.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check kernel 6.6.63 changelog for any Tinker board (rk3288) related changes or issues
# Search for any RK3288 related changes in the kernel
rg -i "rk3288|rockchip" $(fd -t f "Changelog|changes|NEWS" -d 2)
# Check for any reported issues with the kernel version
curl -s "https://raw.githubusercontent.com/torvalds/linux/v6.6.63/Documentation/ABI/stable" | grep -i "rockchip"
Length of output: 65713
Script:
#!/bin/bash
# Check for any known issues or changes related to RK3288 (Tinker board) in kernel 6.6.63 changelog
curl -s https://raw.githubusercontent.com/torvalds/linux/v6.6.63/Documentation/arm/rockchip.rst
# Check kernel config for Tinker board to verify critical drivers are enabled
cat buildroot-external/board/asus/tinker/kernel.config
# Check for any patches specific to Tinker board that might be affected
fd -t f . -E "*.patch" -X grep -l "rk3288.*tinker"
Length of output: 39763
buildroot-external/configs/odroid_xu4_defconfig (1)
20-20: Verify kernel compatibility with Odroid XU4
The kernel version update from 6.6.54 to 6.6.63 needs verification for Exynos platform compatibility.
✅ Verification successful
Based on the gathered information, I can now generate the final response:
Kernel 6.6.63 is compatible with Odroid XU4
The verification shows:
- The board is actively maintained with proper Exynos platform support (exynos5422-odroidxu4.dtb)
- The kernel configuration and patches are platform-specific and maintained
- The only custom patch is for ethernet power management, which is independent of kernel version
- No breaking changes or compatibility issues found for Exynos/Odroid XU4 in the version update
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check kernel 6.6.63 changelog for any Exynos/Odroid XU4 related changes or issues
# Search for any Exynos/Odroid XU4 related changes
rg -i "exynos|odroid.*xu4" $(fd -t f "Changelog|changes|NEWS" -d 2)
# Check for any reported issues with the kernel version
curl -s "https://raw.githubusercontent.com/torvalds/linux/v6.6.63/Documentation/ABI/stable" | grep -i "exynos"
Length of output: 3937
Script:
#!/bin/bash
# Check for any kernel configuration changes or patches specific to Odroid XU4
cat buildroot-external/board/hardkernel/odroid-xu4/kernel.config
# Check kernel patches for Odroid XU4
cat buildroot-external/board/hardkernel/odroid-xu4/patches/linux/0001-ODROID-XU4-regulator-s2mps11-add-ethernet-power-rese.patch
# Check if there are any other kernel patches
fd -t f . buildroot-external/board/hardkernel/odroid-xu4/patches/linux/
# Check device tree for Odroid XU4
cat buildroot-external/board/hardkernel/odroid-xu4/uboot.config
Length of output: 3508
buildroot-external/configs/odroid_n2_defconfig (2)
19-21: LGTM: Coordinated kernel update across platforms
The synchronized update of the Linux kernel from 6.6.54 to 6.6.63 across all platforms (Tinker, Odroid XU4, Odroid N2) is a well-structured change. This minor version update is appropriate for the preparation of version 14.0.
19-19: Verify kernel compatibility with Odroid N2
The kernel version update from 6.6.54 to 6.6.63 needs verification for Amlogic platform compatibility.
✅ Verification successful
Let me analyze the output and generate a final response.
The search results show:
- The Odroid N2 uses the Amlogic platform with the meson-g12b SoC, as evidenced by the DTS files and kernel configurations.
- The repository contains several kernel patches specifically for Amlogic/Odroid N2 support, including power button, fan control, UART, and I2C functionality.
- The kernel version 6.6.63 is already documented as supported for ODROID-N2 in Documentation/kernel.md.
- All necessary kernel configurations and device tree support for Amlogic platform are maintained in the repository.
Kernel update is compatible with Odroid N2
The kernel version update from 6.6.54 to 6.6.63 is a minor version bump that maintains compatibility with the Amlogic platform. The repository includes all necessary Amlogic-specific patches and configurations, and the kernel version is officially documented as supported for ODROID-N2.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check kernel 6.6.63 changelog for any Amlogic/Odroid N2 related changes or issues
# Search for any Amlogic/Odroid N2 related changes
rg -i "amlogic|meson.*g12b|odroid.*n2" $(fd -t f "Changelog|changes|NEWS" -d 2)
# Check for any reported issues with the kernel version
curl -s "https://raw.githubusercontent.com/torvalds/linux/v6.6.63/Documentation/ABI/stable" | grep -i "amlogic"
Length of output: 14477
buildroot-external/configs/rpi4_defconfig (1)
21-21: Verify kernel version compatibility and stability
The kernel source update to stable_20241008.tar.gz aligns with the PR objectives. However, let's verify this version's stability with the Raspberry Pi 4 hardware.
buildroot-external/configs/odroid_m1_defconfig (1)
19-19: Verify kernel version update implications
The kernel version update from 6.6.54 to 6.6.63 is a minor version bump. Let's verify the changelog for any critical fixes or compatibility issues.
✅ Verification successful
Kernel version update is consistent across configurations
The kernel version update from 6.6.54 to 6.6.63 is part of a coordinated update across all device configurations. The search results show:
- All device configurations are using the same kernel version (6.6.63)
- The kernel configuration fragments in
kernel/v6.6.y/are shared across all devices - No version-specific patches that would indicate compatibility issues
- The update maintains hardware support through existing device-specific kernel configurations
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for significant changes between kernel versions
# Check for any kernel config changes required for this version
rg -A 5 "KERNEL.*6\.6\.(54|63)" --type make
# Look for any version-specific patches
fd -t f . "patches" -x grep -l "6.6.54\|6.6.63" {} \;
Length of output: 197
Script:
#!/bin/bash
# Let's verify kernel version changes in buildroot configs and any related patches
# Check kernel version in all defconfigs
rg "BR2_LINUX_KERNEL.*6\.6\." buildroot-external/configs/
# Look for kernel patches in buildroot-external
fd -t f -e patch . buildroot-external/
# Check for any kernel-related changelog or documentation
fd -g "*CHANGELOG*" -g "*README*" . buildroot-external/
Length of output: 22486
buildroot-external/configs/odroid_m1s_defconfig (1)
19-19: LGTM: Consistent kernel version update
The kernel version update to 6.6.63 maintains consistency with the ODROID-M1 configuration, which is the correct approach for these related board variants.
buildroot-external/configs/yellow_defconfig (2)
20-20: Support added for Raspberry Pi CM5
The kernel source and device tree configurations have been updated to support both CM4 and CM5 hardware. This is a significant enhancement that maintains backward compatibility while adding support for newer hardware.
Also applies to: 25-25
✅ Verification successful
Device tree configuration updated for CM5 support
The defconfig file has been updated to include the device tree for both CM4 (bcm2711-rpi-cm4-ha-yellow) and CM5 (bcm2712-rpi-cm5-ha-yellow) hardware. The configuration is properly set up with:
- Device tree support enabled (
BR2_LINUX_KERNEL_DTS_SUPPORT=y) - Both CM4 and CM5 device trees specified in
BR2_LINUX_KERNEL_INTREE_DTS_NAME - Device tree overlay support enabled (
BR2_LINUX_KERNEL_DTB_OVERLAY_SUPPORT=y)
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Verify the device tree files exist in the kernel source
curl -s "https://github.com/raspberrypi/linux/archive/stable_20241008.tar.gz" | tar tz | grep -E "bcm27(11|12)-rpi-cm[45]-ha-yellow.dts"
Length of output: 245
Script:
#!/bin/bash
# Let's verify the device tree configurations in the defconfig file
rg -A5 "BR2_LINUX_KERNEL_DTS_SUPPORT" buildroot-external/configs/yellow_defconfig
# Also check for any CM5-related device tree configurations in the repository
rg -i "cm5" buildroot-external/configs/yellow_defconfig
# Check if there are any device tree files in our repository
fd ".dts$" buildroot-external/
Length of output: 597
146-147: Significant U-Boot updates
The changes include:
- Version upgrade to 2024.10 (major version jump)
- Board configuration changed to rpi_arm64 (from rpi_4)
These changes suggest optimization for ARM64 architecture while potentially improving bootloader capabilities.
✅ Verification successful
The initial verification confirmed the existence of rpi_arm64_defconfig in U-Boot 2024.10. Let's check the previous configuration and any custom patches that might need attention with the version upgrade.
Let's search for U-Boot related files and check the specific changes made to the defconfig file to better understand the upgrade impact.
Let's examine the Yellow board-specific U-Boot configurations and patches to ensure compatibility with the new version and ARM64 configuration.
U-Boot upgrade and board configuration changes are compatible
The verification confirms:
- The Yellow board's U-Boot configuration is compatible with ARM64, as evidenced by the existing
uboot-boot64.ushscript and board configuration. - The board-specific patches are minimal and focus on UART functionality, which are not affected by the version upgrade.
- The configuration uses BCM2712 SoC support, which aligns with the ARM64 architecture.
The change from rpi_4 to rpi_arm64 board configuration is appropriate for the hardware and matches the existing 64-bit boot setup.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Verify U-Boot version compatibility
curl -s "https://ftp.denx.de/pub/u-boot/u-boot-2024.10.tar.bz2" | tar tj | grep -E "configs/rpi_arm64_defconfig"
Length of output: 153
Script:
#!/bin/bash
# Check previous U-Boot version and board config
git log -1 --before="2024-01-01" -- buildroot-external/configs/yellow_defconfig | grep -E "BR2_TARGET_UBOOT"
# Check if there are any custom patches or configurations for U-Boot
fd -e patch -e config . buildroot-external/board/yellow/uboot
Length of output: 188
Script:
#!/bin/bash
# Let's try a different approach to find U-Boot related files and configurations
fd uboot buildroot-external
# Check for any U-Boot patches or configurations in the board directory
fd -t f . buildroot-external/board --glob "*uboot*"
# Look for previous version in git history
git diff HEAD~1 buildroot-external/configs/yellow_defconfig
Length of output: 2547
Script:
#!/bin/bash
# Check the specific U-Boot configuration for Yellow board
cat buildroot-external/board/raspberrypi/yellow/uboot.config
# Check for any U-Boot patches specific to Yellow
fd . buildroot-external/board/raspberrypi/yellow/patches/uboot/
# Check the boot script for Yellow
cat buildroot-external/board/raspberrypi/yellow/uboot-boot64.ush
Length of output: 3994
buildroot-external/configs/green_defconfig (1)
19-19: Kernel version updated to 6.6.63
The kernel version update is part of a coordinated update across all platforms, likely including security fixes and stability improvements.
✅ Verification successful
Kernel version 6.6.63 update verified across all platform configurations
The verification confirms that:
- The kernel version update to 6.6.63 is consistently applied across all 12 platform configurations
- All defconfig files in buildroot-external/configs/ have been updated to the same version
- This is part of a larger OS release update to version 14.0
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for security advisories for kernel 6.6.63
gh api graphql -f query='
{
securityVulnerabilities(first: 5, ecosystem: LINUX, package: "kernel", range: "6.6.63") {
nodes {
advisory {
summary
severity
publishedAt
}
}
}
}'
Length of output: 1051
Script:
#!/bin/bash
# Check for other defconfig files to verify coordinated update
fd -e defconfig -x grep -l "BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE" {}
# Show the kernel version in each defconfig file
fd -e defconfig -x grep "BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE" {}
# Check git history for related changes
git log -n 5 --oneline -- "*defconfig"
Length of output: 140
Script:
#!/bin/bash
# Try finding defconfig files in buildroot-external directory
find buildroot-external -name "*defconfig" -type f -exec grep -l "BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE" {} \;
# Show the kernel version in found defconfig files
find buildroot-external -name "*defconfig" -type f -exec grep "BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE" {} \;
# Check the commit message for more context
git show --pretty=format:"%s%n%b" -s HEAD
Length of output: 1428
buildroot-external/configs/generic_aarch64_defconfig (1)
19-19: Kernel version updated to 6.6.63
Consistent with other platform updates, ensuring unified kernel version across the ecosystem.
buildroot-external/configs/generic_x86_64_defconfig (2)
74-74: LGTM: Intel Wi-Fi GL firmware support added.
The addition of BR2_PACKAGE_LINUX_FIRMWARE_IWLWIFI_GL=y enhances hardware compatibility by adding support for Intel Wi-Fi GL devices.
19-19: Verify kernel update compatibility.
The kernel version update from 6.6.54 to 6.6.63 appears to be a maintenance update. Let's verify the changelog for any breaking changes.
✅ Verification successful
Kernel update from 6.6.54 to 6.6.63 appears safe to proceed
This is a minor version update within the stable 6.6.x series, which typically contains only bug fixes and security patches. The change from 6.6.54 to 6.6.63 represents standard maintenance updates without breaking changes. The defconfig shows standard Linux kernel configuration without any special version-dependent features that would be affected by this minor version bump.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check kernel changelog for breaking changes between versions
# Get kernel changelog
curl -s https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.6.63 | grep -A 10 "^Changes between.*6.6.54.*6.6.63"
Length of output: 119
Script:
#!/bin/bash
# Let's check the kernel configuration and related files for any specific dependencies or configurations
# Check kernel config file and related files
fd -e config -e defconfig | xargs cat
# Check for any kernel-related documentation or README files
fd -g "*README*" -g "*KERNEL*" -t f | xargs cat
# Look for any kernel version references in the codebase
rg "LINUX_KERNEL.*VERSION" -A 2 -B 2
Length of output: 75934
Script:
#!/bin/bash
# Let's check for any kernel version dependencies or requirements in the repository
# Look for kernel version references in documentation
rg -i "kernel.*6\.6\." --type txt --type md
# Check for any build scripts or configuration files that might specify kernel version requirements
rg -i "kernel.*version" --type yaml --type sh --type conf
# Look specifically for kernel version changes in recent commits
git log -n 10 --grep="kernel" --pretty=format:"%h %s"
Length of output: 134
buildroot-external/configs/ova_defconfig (1)
19-19: LGTM: Changes consistent with generic_x86_64_defconfig.
The kernel version update and Intel Wi-Fi GL firmware addition mirror the changes in generic_x86_64_defconfig, maintaining consistency across configurations.
Also applies to: 76-76
.github/workflows/build.yaml (1)
147-147: Verify docker/build-push-action update compatibility.
The update from v6.9.0 to v6.10.0 is a minor version bump. Let's verify the changes in this version.
✅ Verification successful
Update to docker/build-push-action@v6.10.0 is safe to proceed
The changes in v6.10.0 are minor and include:
- Addition of optional
callinput parameter - Dependencies security updates and version bumps
- No breaking changes or deprecations
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check release notes for docker/build-push-action
# Get release notes
gh api repos/docker/build-push-action/releases/tags/v6.10.0 --jq .body
Length of output: 598
| disable_data_partition() { | ||
| e2label "${1}" hassos-data-dis | ||
| } |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Add error handling in the disable_data_partition function
The disable_data_partition function currently does not check if the e2label command executes successfully. Consider adding error handling to ensure robustness.
You can modify the function to handle errors as follows:
disable_data_partition() {
if ! e2label "${1}" hassos-data-dis; then
echo "Error: Failed to disable data partition ${1}" >&2
fi
}| for datapart in ${datapartitions}; do | ||
| datadev=$(lsblk -no pkname "${datapart}") | ||
|
|
||
| case "${datadev}" in | ||
| mmc*) | ||
| # Data partition on internal eMMC | ||
| if [ "$rootdev" = "$datadev" ]; then | ||
| emmc_data_partition="${datapart}" | ||
| fi | ||
| ;; | ||
| nvme0*) | ||
| # Data partition on first NVMe disk | ||
| nvme_data_partition="${datapart}" | ||
| ;; | ||
| *) | ||
| # Disable all other data disks as normally | ||
| if [ "$rootdev" != "$datadev" ]; then | ||
| echo "Found extra external data disk device on ${datapart}, marking it disabled..." | ||
| disable_data_partition "${datapart}" | ||
| fi | ||
| ;; | ||
| esac | ||
| done |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Handle multiple NVMe devices in the case statement
The current case pattern matches only nvme0*, which means it will not detect additional NVMe devices like nvme1, nvme2, etc. If the system can have multiple NVMe devices, consider updating the pattern.
Modify the case statement to include all NVMe devices:
nvme*)
# Data partition on NVMe disk
nvme_data_partition="${datapart}"
;;| @@ -3,6 +3,7 @@ set -e | |||
|
|
|||
| build_dir=$1 | |||
| dst_dir=$2 | |||
| channel=$3 | |||
There was a problem hiding this comment.
🛠️ Refactor suggestion
Verify channel parameter validation.
The script accepts the channel parameter but doesn't validate its value. Consider adding validation to ensure only valid channels (stable, beta, dev) are accepted.
channel=$3
+
+# Validate channel
+if [[ ! "${channel}" =~ ^(stable|beta|dev)$ ]]; then
+ echo "Error: Invalid channel. Must be one of: stable, beta, dev"
+ exit 1
+fi📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| channel=$3 | |
| channel=$3 | |
| # Validate channel | |
| if [[ ! "${channel}" =~ ^(stable|beta|dev)$ ]]; then | |
| echo "Error: Invalid channel. Must be one of: stable, beta, dev" | |
| exit 1 | |
| fi |
| channel=$1 | ||
|
|
There was a problem hiding this comment.
🛠️ Refactor suggestion
Add parameter validation
The script accepts a channel parameter but doesn't validate it. Consider adding validation to ensure:
- The parameter is provided
- It contains a valid channel value (stable/beta/dev)
+if [ -z "$1" ]; then
+ echo "Error: Channel parameter is required"
+ exit 1
+fi
+
+case "$1" in
+ stable|beta|dev) ;;
+ *)
+ echo "Error: Invalid channel '$1'. Must be stable, beta, or dev"
+ exit 1
+ ;;
+esac
+
channel=$1📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| channel=$1 | |
| if [ -z "$1" ]; then | |
| echo "Error: Channel parameter is required" | |
| exit 1 | |
| fi | |
| case "$1" in | |
| stable|beta|dev) ;; | |
| *) | |
| echo "Error: Invalid channel '$1'. Must be stable, beta, or dev" | |
| exit 1 | |
| ;; | |
| esac | |
| channel=$1 |
|
|
||
| echo "{ \"channel\": \"${channel}\" }" > /data/supervisor/updater.json |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Add directory existence check and set file permissions
The script creates updater.json but should ensure:
- The target directory exists
- Proper file permissions are set
+# Ensure supervisor directory exists
+mkdir -p "/data/supervisor"
+
echo "{ \"channel\": \"${channel}\" }" > /data/supervisor/updater.json
+# Set restrictive permissions as this file affects update behavior
+chmod 644 /data/supervisor/updater.json📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| echo "{ \"channel\": \"${channel}\" }" > /data/supervisor/updater.json | |
| # Ensure supervisor directory exists | |
| mkdir -p "/data/supervisor" | |
| echo "{ \"channel\": \"${channel}\" }" > /data/supervisor/updater.json | |
| # Set restrictive permissions as this file affects update behavior | |
| chmod 644 /data/supervisor/updater.json |
| # Deploy only landing page for "core" by setting version to "landingpage" | ||
| curl -s $(HASSIO_VERSION_URL) | jq '.core = "landingpage"' > $(@D)/stable.json | ||
| curl -s $(HASSIO_VERSION_URL)$(HASSIO_VERSION_CHANNEL)".json" | jq '.core = "landingpage"' > $(@D)/version.json | ||
| endef |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Consider error handling for version file download
The curl command should handle network failures and invalid JSON responses.
-curl -s $(HASSIO_VERSION_URL)$(HASSIO_VERSION_CHANNEL)".json" | jq '.core = "landingpage"' > $(@D)/version.json
+curl -f -s $(HASSIO_VERSION_URL)$(HASSIO_VERSION_CHANNEL)".json" > $(@D)/version.json.tmp && \
+jq '.core = "landingpage"' $(@D)/version.json.tmp > $(@D)/version.json || \
+ (rm -f $(@D)/version.json.tmp && exit 1)📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| # Deploy only landing page for "core" by setting version to "landingpage" | |
| curl -s $(HASSIO_VERSION_URL) | jq '.core = "landingpage"' > $(@D)/stable.json | |
| curl -s $(HASSIO_VERSION_URL)$(HASSIO_VERSION_CHANNEL)".json" | jq '.core = "landingpage"' > $(@D)/version.json | |
| endef | |
| # Deploy only landing page for "core" by setting version to "landingpage" | |
| curl -f -s $(HASSIO_VERSION_URL)$(HASSIO_VERSION_CHANNEL)".json" > $(@D)/version.json.tmp && \ | |
| jq '.core = "landingpage"' $(@D)/version.json.tmp > $(@D)/version.json || \ | |
| (rm -f $(@D)/version.json.tmp && exit 1) | |
| endef |
| if [ "${RAUC_SLOT_CLASS}" = "boot" ]; then | ||
| post_install_boot | ||
| fi |
There was a problem hiding this comment.
💡 Codebase verification
Function post_install_boot is missing from the script
The script calls post_install_boot in the slot-post-install case, but the function is not defined anywhere in the file. This is a potential bug that could lead to undefined behavior when the script processes a boot slot.
🔗 Analysis chain
Verify post_install_boot implementation.
The script calls post_install_boot but its implementation is not visible in the provided context. This could lead to undefined behavior if the function is not properly defined.
Let me search for the actual implementation of post_install_boot function.
Let me try a different approach to find the function definition.
Let me try one final approach to find the function by looking at the entire file content.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for post_install_boot implementation
rg -l "post_install_boot()"
Length of output: 62
Script:
#!/bin/bash
# Search for post_install_boot implementation with context
rg -A 10 "^post_install_boot\(\)" buildroot-external/ota/rauc-hook
Length of output: 68
Script:
#!/bin/bash
# Search for post_install_boot definition with more flexible pattern
rg -A 10 "post_install_boot\s*\(\s*\)" buildroot-external/ota/rauc-hook
Length of output: 73
Script:
#!/bin/bash
# View the entire content of the rauc-hook file
cat buildroot-external/ota/rauc-hook
Length of output: 4754
Summary by CodeRabbit
New Features
fileenvin U-Boot to read files from FAT32 and store contents in environment variables.create-data-partition.shscript to accept a channel parameter for improved flexibility in data partition management.Improvements
systemd-time-wait-sync.servicefrom 90 seconds to 15 seconds to improve boot efficiency.haos-data-disk-detachscript for better management based on device type.Bug Fixes
Documentation