Fix/hi3518ev300 rootfs overflow

[andy2997j-ai]

No description provided.

[qodo-free-for-open-source-projects]

PR Summary by Qodo

Add Morse Micro HaLow and reduce RunCam WiFiLink rootfs size

🐞 Bug fix ✨ Enhancement ⚙️ Configuration changes 🕐 10-20 Minutes

AI Description

• Replaces unused Realtek FPV drivers with Morse Micro HaLow on RunCam WiFiLink.
• Adds Buildroot metadata to fetch and compile the Morse Micro kernel module.
• Reduces rootfs pressure while preserving the required FPV wireless driver.

Diagram

graph TD
  A["RunCam defconfig"] --> B["Buildroot config"] --> C["Morse package"] --> D["Driver source"] --> E["Kernel module"] --> G["Firmware rootfs"]
  A -. excludes .-> F["Realtek modules"]

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Register as a shared extra package

• ➕ Matches the repository's existing package discovery and copy mechanism
• ➕ Makes the driver reusable by other device configurations
• ➕ Keeps Buildroot package metadata alongside other extra packages
• ➖ Registers the package globally even when only one device currently selects it

2. Use a device-local package overlay

• ➕ Scopes the driver recipe to the RunCam WiFiLink target
• ➕ Avoids exposing an experimental driver to unrelated devices
• ➖ Requires additional device-overlay wiring
• ➖ Makes reuse and maintenance harder across future HaLow targets

Recommendation: Keep the strategy of replacing unused Realtek drivers with Morse Micro because it directly addresses constrained image size. However, place the recipe under package/morse-micro or explicitly wire its current top-level directory into Buildroot; builder.sh only copies and registers children of package/, so the current location may leave BR2_PACKAGE_MORSE_MICRO undiscovered. Pin a tested commit or release instead of master for reproducible builds, and align the PR title with the changed SSC338Q RunCam target rather than HI3518EV300.

Files changed (3) +22 / -2

Bug fix (1) +6 / -2

ssc338q_fpv_runcam-wifilink_defconfigReplace Realtek FPV drivers with Morse Micro HaLow +6/-2

Replace Realtek FPV drivers with Morse Micro HaLow

• Disables the RTL88X2EU and RTL8812AU packages to reduce firmware size. Enables the Morse Micro package as the retained HaLow wireless driver for RunCam WiFiLink.

devices/ssc338q_fpv_runcam-wifilink/br-ext-chip-sigmastar/configs/ssc338q_fpv_runcam-wifilink_defconfig

Other (2) +16 / -0

Config.inExpose the Morse Micro Buildroot package option +4/-0

Expose the Morse Micro Buildroot package option

• Defines 'BR2_PACKAGE_MORSE_MICRO' and documents it as the OpenIPC Wi-Fi HaLow driver package.

morse-micro/Config.in

morse-micro.mkAdd the Morse Micro kernel-module recipe +12/-0

Add the Morse Micro kernel-module recipe

• Fetches 'mm-wifi-linux' from the upstream Git repository at its 'master' branch. Registers the source as both a Buildroot kernel-module and generic package.

morse-micro/morse-micro.mk

[qodo-free-for-open-source-projects]

Code Review by Qodo

🐞 Bugs (1) 📘 Rule violations (1) 📜 Skill insights (0)

1. Firmware lacks its wireless driver 📘 Rule violation ≡ Correctness

Description

copy_extra_packages scans only children of package/, but the new Config.in and
morse-micro.mk are placed in the repository-root morse-micro/ directory. During RunCam device
builds, BR2_PACKAGE_MORSE_MICRO=y has no imported definition, so neither package file is copied or
sourced and the intended HaLow replacement for the removed Realtek drivers does not reach the target
firmware.

Code

morse-micro/Config.in[1]

+config BR2_PACKAGE_MORSE_MICRO

Evidence

The builder explicitly copies extra packages and generates configuration source entries only for
children of the repository's package/ directory, as demonstrated by the existing demo package
layout. Because the Morse Micro files instead reside at repository-root morse-micro/ while the
device defconfig enables their symbol, the build never imports the selected package; this violates
the requirements that builder-local packages use a discoverable Buildroot structure and that the
selected wireless package be available to the device.

CLAUDE.md: Builder-Local Packages Must Follow Buildroot Package Structure
CLAUDE.md: Defconfig Names and Hardware Settings Must Match the Device
morse-micro/Config.in[1-4]
morse-micro/morse-micro.mk[7-12]
builder.sh[98-110]
devices/ssc338q_fpv_runcam-wifilink/br-ext-chip-sigmastar/configs/ssc338q_fpv_runcam-wifilink_defconfig[64-69]
builder.sh[104-115]
builder.sh[143-144]
package/demo-openipc/Config.in[1-7]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The Morse Micro package is outside the builder-local `package/` directory, so the builder does not copy or register it and the RunCam device defconfig cannot build its wireless driver.

## Fix Focus Areas
- morse-micro/Config.in[1-4]
- morse-micro/morse-micro.mk[1-12]
- builder.sh[104-115]

## Recommended Fix
Move the complete `morse-micro` directory to `package/morse-micro/`, preserving the names and contents of `Config.in` and `morse-micro.mk`. This lets `copy_extra_packages` copy the directory into `general/package` and automatically append its `Config.in` source entry before processing the device defconfig.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. Pinned builds fetch changing driver code 🐞 Bug ☼ Reliability

Description

MORSE_MICRO_VERSION names the mutable master branch rather than an immutable revision. Fresh
builds—and even workflows using OPENIPC_FW_REV to pin firmware for regression bisection—can
therefore compile different driver code from the same builder and firmware commits.

Code

morse-micro/morse-micro.mk[7]

+MORSE_MICRO_VERSION = master

Evidence

The package selects master from a Git repository, while the builder explicitly supports pinning
the firmware repository to a tag or SHA for size and regression investigations. Leaving this second
source mutable means that pin does not determine all source code used by the build.

morse-micro/morse-micro.mk[7-9]
builder.sh[121-130]
.github/workflows/build-one.yml[87-87]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The package fetches the moving upstream `master` branch, making otherwise pinned builds depend on whichever driver revision is current at build time.

## Fix Focus Areas
- morse-micro/morse-micro.mk[7-9]
- builder.sh[121-130]

## Recommended Fix
Replace `MORSE_MICRO_VERSION = master` with a tested immutable upstream commit SHA or release tag. Update that revision explicitly when adopting newer driver code.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

Context sources

Review mode: ⚖️ Balanced: This changes Buildroot configuration and adds a kernel module package from a moving Git branch, creating meaningful build and runtime integration risk despite the small diff.

Tip of the day

💡 Did you know, you can turn on the rule miner and Qodo learns your standards from review history

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

[qodo-free-for-open-source-projects]

1. Firmware lacks its wireless driver 📘 Rule violation ≡ Correctness

copy_extra_packages scans only children of package/, but the new Config.in and
morse-micro.mk are placed in the repository-root morse-micro/ directory. During RunCam device
builds, BR2_PACKAGE_MORSE_MICRO=y has no imported definition, so neither package file is copied or
sourced and the intended HaLow replacement for the removed Realtek drivers does not reach the target
firmware.

Agent Prompt

## Issue description
The Morse Micro package is outside the builder-local `package/` directory, so the builder does not copy or register it and the RunCam device defconfig cannot build its wireless driver.

## Fix Focus Areas
- morse-micro/Config.in[1-4]
- morse-micro/morse-micro.mk[1-12]
- builder.sh[104-115]

## Recommended Fix
Move the complete `morse-micro` directory to `package/morse-micro/`, preserving the names and contents of `Config.in` and `morse-micro.mk`. This lets `copy_extra_packages` copy the directory into `general/package` and automatically append its `Config.in` source entry before processing the device defconfig.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

[qodo-free-for-open-source-projects]

2. Pinned builds fetch changing driver code 🐞 Bug ☼ Reliability

MORSE_MICRO_VERSION names the mutable master branch rather than an immutable revision. Fresh
builds—and even workflows using OPENIPC_FW_REV to pin firmware for regression bisection—can
therefore compile different driver code from the same builder and firmware commits.

Agent Prompt

## Issue description
The package fetches the moving upstream `master` branch, making otherwise pinned builds depend on whichever driver revision is current at build time.

## Fix Focus Areas
- morse-micro/morse-micro.mk[7-9]
- builder.sh[121-130]

## Recommended Fix
Replace `MORSE_MICRO_VERSION = master` with a tested immutable upstream commit SHA or release tag. Update that revision explicitly when adopting newer driver code.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

[openipc-ai]

Thanks for this — you have found a real problem, so let me start there before
explaining why I am closing the PR as it stands.

ssc338q_fpv_runcam-wifilink genuinely does not fit. In the last full matrix
run it failed with:

- rootfs.squashfs: [8276KB/8192KB]
-- size exceeded by: 84KB

So the overflow is real and worth fixing. Three things get in the way of this
particular change, though.

The title does not match the diff. It says hi3518ev300, but nothing under
devices/hi3518ev300* is touched — the change is entirely the SSC338Q FPV
board. Worth knowing in case you were aiming at a different camera.

The overflow is family-wide, not specific to this board. In the same run
ssc338q_fpv_caddx-fly, ssc338q_fpv_openipc-mario-aio and ssc338q_apfpv
all broke the same cap. When several images in a family cross together it is
almost always upstream drift — majestic and majestic-webui are fetched from
moving refs, so a build that looks identical can ship a materially larger
image, and whichever boards sit closest to the cap break first. That points at
a family-wide fix rather than removing a driver from one profile.

As written, the change only subtracts. copy_extra_packages() in
builder.sh copies ${BUILDER_DIR}/package/* and appends a source line per
entry to the external tree's Config.in. morse-micro/ is at the repository
root rather than under package/, so it is never copied and its Config.in is
never sourced. That means BR2_PACKAGE_MORSE_MICRO is not a real Kconfig
symbol, and Buildroot drops unknown symbols when it expands a defconfig instead
of failing — silently. The two Realtek drivers would be removed, nothing would
be added, and the camera would ship with no Wi-Fi driver at all.

Two follow-on points on the package itself: https://github.com/morsemicro/mm-wifi-linux
returns 404. The vendor's GitHub org is capitalised as MorseMicro and the
driver lives at MorseMicro/morse_driver — there is no mm-wifi-linux. And
for the radio: every ssc338q_fpv profile in the tree ships both
RTL88X2EU and RTL8812AU (thinker-aio swaps the first for RTL8733BU)
because the adapter is whatever the pilot fits. BR2_PACKAGE_WIFIBROADCAST_NG=y
stays set here, and wfb-ng needs an 8812au/88x2eu-class adapter in monitor
mode, so dropping both removes what the board is for.

Two small things for next time: the repository language is English, and the two
new defconfig comments are Italian notes written in the second person, which
reads as a personal bench note in a file everyone shares. A sentence or two in
the PR description also helps a lot — this one was empty, which is why the
mismatch with the title took a while to unpick.

If you want to pursue HaLow on this board, please open it as its own PR: the
package under package/morse-micro/ (use package/kc110-board-support as the
template), pointed at MorseMicro/morse_driver, and with the Realtek drivers
left alone. That is a feature proposal worth discussing on its own merits.

Closing this one, but please do come back with the HaLow package — and thanks
for surfacing the size failure.