kernel: drop what no hi3518ev200 or ssc333 board can load, so the 8M lite boards fit again by openipc-ai · Pull Request #2399 · OpenIPC/firmware

openipc-ai · 2026-09-11T18:33:57Z

What broke

Three boards fail the rootfs cap on the current nightly, and nothing in either
repository grew to do it:

hi3518ev200_lite_switcam-hs303      rootfs.squashfs: [5136KB/5120KB]  -- size exceeded by: 16KB
ssc333_lite_meari-speed-6s          rootfs.squashfs: [5128KB/5120KB]  -- size exceeded by: 8KB
ssc333_lite_babysense-see-hd-ip206  rootfs.squashfs: [5128KB/5120KB]  -- size exceeded by: 8KB

Diffing every downloaded tarball between the last green full matrix
(builder run 34390937880, 09-09 18:45 UTC) and the red one (34605828158,
09-11 13:42), exactly two inputs changed size:

input	09-09	09-11	delta
`majestic.<family>.lite.master.tar.bz2`	1,268,757	1,286,854	+18,097 B
`majestic-webui-dist.tar.gz`	294,421	300,323	+5,902 B

Both are unpinned moving refs, so the growth lands with no pull request to point
at — the same shape as #2397, one nightly later. It is uniform across boards:
ssc333_lite_tp-link-tapo-c110-v26, which still passes, went 5060 → 5084KB.
The three that broke are the three boards of these families that were already
within 16KB of the cap, all of them carrying the out-of-tree RTL8188FU driver.

What changes

Nothing is removed that any of these boards can use. Four changes, all of them
the pattern from #2376 and #2397, applied to the three kernel configs that back
the failing boards.

1. The SCSI stack is dropped from hi3518ev200.generic.config and both
infinity6b0-ssc009{a,b}.config. Nothing can reach it on either platform:
CONFIG_USB_STORAGE is unset, CONFIG_ATA is unset, no SCSI low-level host
driver is enabled, and SD cards arrive through CONFIG_MMC_BLOCK=y as
mmcblk, not sd. Same argument and same shape as #2376. CONFIG_SCSI_MOD=y
is what olddefconfig derives once CONFIG_SCSI is off.

On hi3518ev200 it was =m, so scsi_mod.ko (145KB) and sd_mod.ko (37KB)
were shipping in every rootfs of the family. On infinity6b0 it was =y, so it
was costing kernel rather than rootfs — which is what pays for change 3 below.

2. The in-kernel Realtek USB Wi-Fi stack is dropped from
hi3518ev200.generic.config: rtl8xxxu.ko (104KB), rtl8192cu.ko (90KB),
rtlwifi.ko (85KB), rtl8192c-common.ko (54KB) and rtl_usb.ko (15KB) ship in
every hi3518ev200 rootfs and no board loads them. Every wlandev profile in
general/overlay/etc/wireless/usb that serves this family modprobes an
out-of-tree driver instead —

rtl8188fu-hi3518ev200-lifesmart      modprobe 8188fu
rtl8188fu-switcam-hs303              modprobe 8188fu
rtl8188eus-hi3518ev200-lenovo        modprobe 8188eu
rtl8188eu-hi3518ev200-qvc-ipc-136w   modprobe 8188eu
rtl8188eus-switcam-hs303v2           modprobe 8188eu

— and the one board of the eight that is not Realtek at all
(hi3518ev200_lite_vstarcam-c8892wip) uses mt7601u-generic, so
CONFIG_MT7601U=m is deliberately left alone. CONFIG_RTLWIFI_DEBUG=y was set,
which is why rtlwifi.ko was as large as it was.

3. FAT/VFAT are built in on hi3518ev200 instead of shipping as modules.
Every SD card mounted on these boards needs them and /etc/modules loads
vfat on every boot anyway, so this moves bytes from the rootfs into the
kernel partition rather than dropping anything. NLS was already built in, so
nothing new is pulled in.

4. cryptodev, ms_notify and echainiv are dropped from both infinity6b0
configs. All three ship as modules that nothing ever loads: they are absent from
load_sigmastar's insmod list and from /etc/modules (which carries only
vfat and exfat), no script in the overlay modprobes them, and no string in
majestic, libmbedcrypto, curl, load_sigmastar or any of the mi_*/mhal
vendor modules mentions cryptodev, /dev/crypto, ms_notify or echainiv.
A module that is never loaded provides nothing at runtime, so dropping them
changes no behaviour while freeing both rootfs and kernel — unlike building
them in, which would have made unused code permanently resident.

Nothing selects CONFIG_CRYPTO_ECHAINIV back: there is no IPsec on these
configs (INET_ESP, INET_AH, XFRM_USER and NET_KEY are all unset), and
CONFIG_CRYPTO_SEQIV=y is a separate symbol left alone. CONFIG_MS_CRYPTO=y,
the hardware engine itself, is also left alone — only the unused /dev/crypto
userspace interface goes.

Measured

Local from-scratch builds of this branch against firmware master at dac15a7 (this branch rebased onto a8054df, which only
touched .github/scripts/ci-matrix.py),
compared with a baseline build of the same tree with only these config changes
reverted. Both clean full builds — an incremental one is not trustworthy here,
because linux-reconfigure leaves the .ko files of the previous config in
output/build/linux-custom and modules_install copies them straight back, so
the kernel shrinks while the rootfs does not move at all.

board	uImage before → after (of 2048KB)	rootfs before → after (of 5120KB)
`hi3518ev200_lite_switcam-hs303`	1776 → 1795	5144 → 4944
`ssc333_lite_meari-speed-6s`	2001 → 1956	5132 → 5100

Note the baselines are worse than the failing CI run recorded (5136 and 5128) —
majestic has drifted a further 8KB and 4KB since Thursday, which is the point.

On hi3518ev200 the kernel grows 19KB, exactly what #2376 measured for the same
FAT/VFAT move, and the rootfs loses 200KB. The module count goes 63 → 54, and in
the built tree kernel/drivers/scsi, kernel/fs/fat and
kernel/drivers/net/wireless/realtek are gone from /lib/modules while
modules.builtin carries fs/fat/fat.ko and fs/fat/vfat.ko. 8188fu.ko,
mac80211.ko and cfg80211.ko are all still there.

On infinity6b0 the kernel shrinks 45KB, because SCSI was =y there rather
than =m — so this buys back kernel headroom on a board that only had 48KB of
it, as well as taking the rootfs under the cap. The patched rootfs carries
8188fu, exfat, wireguard, the twelve mi_*/mhal modules and
sensor_jxf37_mipi.ko, with /etc/sensors/jxf37.bin the only sensor blob left
— which is the whole of what this board uses.

The effective .config after Buildroot's olddefconfig is
CONFIG_SCSI_MOD=y + # CONFIG_SCSI is not set on both platforms, with
CONFIG_MS_CRYPTO=y and CONFIG_MT7601U=m untouched — nothing was re-enabled
behind the change.

Not tested on hardware

I have no unit of any of these three boards on the bench, so this is measured
from builds only. The two kernel-config moves are the ones #2376 and #2397
already made on Goke and hi3518ev300, and the reasoning for each dropped symbol
is stated above so it can be checked rather than taken on trust. The specific
things worth exercising on a real camera before this is trusted:

an SD card still mounts on a hi3518ev200 board, with FAT/VFAT built in rather
than modular (/proc/filesystems should list vfat with no module loaded,
and modprobe vfat from S35modules should still exit 0);
Wi-Fi still associates on a hi3518ev200 board — 8188fu and 8188eu are
out-of-tree packages and untouched here, but they sit on mac80211/cfg80211,
which stay modular (CONFIG_MAC80211=m, CONFIG_CFG80211=m) and are not
touched by dropping RTL_CARDS/RTL8XXXU;
an infinity6b0 board still boots and streams with cryptodev, ms_notify and
echainiv gone. If anyone knows of a consumer of /dev/crypto on Sigmastar
that I could not find in the image, say so and I will keep CONFIG_CRYPTODEV.

…lite boards fit again Three boards are over the 5120KB rootfs cap on the current nightly and nothing in either repository grew to do it: majestic's master tarball gained 18,097 B and majestic-webui's dist asset 5,902 B between 09-09 and 09-11, both unpinned moving refs. The uniform ~23KB pushed over the three boards that were already within 16KB of the cap. The SCSI stack goes from hi3518ev200.generic.config and both infinity6b0-ssc009{a,b}.config. Nothing can reach it on either platform: CONFIG_USB_STORAGE and CONFIG_ATA are unset, no SCSI low-level host driver is enabled, and SD cards arrive through CONFIG_MMC_BLOCK as mmcblk, not sd. Same argument and same shape as #2376; CONFIG_SCSI_MOD=y is what olddefconfig derives once CONFIG_SCSI is off. The in-kernel Realtek USB Wi-Fi stack goes from hi3518ev200.generic.config. rtl8xxxu, rtl8192cu, rtlwifi, rtl8192c-common and rtl_usb ship in every hi3518ev200 rootfs and no board loads them: every wlandev profile serving this family modprobes an out-of-tree 8188fu or 8188eu, and the one non-Realtek board uses mt7601u, so CONFIG_MT7601U is deliberately left alone. CONFIG_MAC80211 and CONFIG_CFG80211 stay modular. FAT and VFAT are built into the hi3518ev200 kernel instead of shipping as modules. Every SD card needs them and /etc/modules loads vfat on every boot, so the bytes move into the kernel partition rather than being dropped. NLS was already built in. cryptodev, ms_notify and echainiv go from both infinity6b0 configs. All three ship as modules nothing ever loads: absent from load_sigmastar's insmod list and from /etc/modules, unreferenced by any overlay script, and no string in majestic, libmbedcrypto, curl or the mi_*/mhal vendor modules mentions them. A module that is never loaded provides nothing, so dropping frees both rootfs and kernel where building them in would have made unused code resident. Nothing selects CONFIG_CRYPTO_ECHAINIV back - there is no IPsec on these configs - and CONFIG_MS_CRYPTO, the hardware engine itself, is untouched.

qodo-free-for-open-source-projects · 2026-09-11T18:35:09Z

PR Summary by Qodo

Trim unused kernel features to restore 8 MiB lite board builds

🐞 Bug fix ⚙️ Configuration changes 🕐 20-40 Minutes

AI Description

• Removes unreachable SCSI and unused modules from HiSilicon and SigmaStar kernels.
• Drops unused Realtek drivers while preserving board-specific external Wi-Fi modules.
• Builds FAT/VFAT into Hi3518EV200, restoring compliance with the 5 MiB rootfs cap.

Diagram

graph TD
  H["HiSilicon config"] --> HT["Trim SCSI Wi-Fi"] --> R[("Rootfs image")]
  H --> F["Build FAT/VFAT in"] --> K[("Kernel image")]
  S["SigmaStar configs"] --> ST["Trim SCSI modules"] --> K
  ST --> R

High-Level Assessment

The following are alternative approaches to this PR:

1. Pin external firmware assets

➕ Makes nightly image sizes reproducible
➕ Forces dependency growth through explicit updates
➖ Does not reclaim space for necessary future growth
➖ Requires ongoing maintenance and may delay upstream fixes

2. Prune modules after installation

➕ Can reduce rootfs size without changing kernel feature selection
➕ Allows one broader kernel configuration across boards
➖ Still builds unused functionality
➖ Can leave misleading configuration and dependency metadata
➖ Risks reintroducing modules during packaging changes

3. Change flash partition layout

➕ Could provide more rootfs headroom long-term
➖ Risks incompatibility with bootloaders and existing installations
➖ Consumes limited space elsewhere on 8 MiB devices
➖ Requires significantly broader hardware validation

Recommendation: Keep the kernel-configuration pruning: it removes functionality shown to be unreachable and yields measured space savings without altering the fixed flash layout. Pinning moving external assets is a worthwhile separate reproducibility improvement, but it does not replace reclaiming unused kernel footprint; hardware smoke tests should confirm SD mounting, Wi-Fi association, and SigmaStar streaming.

Files changed (3) +14 / -115

Other (3) +14 / -115

hi3518ev200.generic.configTrim unused drivers and build FAT support into Hi3518EV200 +6/-41

Trim unused drivers and build FAT support into Hi3518EV200
• Disables the unreachable SCSI stack and unused in-kernel Realtek USB Wi-Fi drivers while retaining MT7601U and external board-specific drivers. Builds FAT and VFAT into the kernel, moving required SD-card support out of the size-constrained rootfs.
br-ext-chip-hisilicon/board/hi3516cv200/hi3518ev200.generic.config

infinity6b0-ssc009a.configRemove unused SSC009A storage and crypto modules +4/-37

Remove unused SSC009A storage and crypto modules
• Disables SCSI, cryptodev, ms_notify, and echainiv while preserving the SigmaStar hardware crypto engine and sequence IV support. This reduces both kernel and rootfs usage for SSC009A-based lite boards.
br-ext-chip-sigmastar/board/infinity6b0/infinity6b0-ssc009a.config

infinity6b0-ssc009b.configRemove unused SSC009B storage and crypto modules +4/-37

Remove unused SSC009B storage and crypto modules
• Mirrors the SSC009A trimming by disabling unreachable SCSI support and unused cryptodev, ms_notify, and echainiv modules. Required hardware crypto functionality remains enabled.
br-ext-chip-sigmastar/board/infinity6b0/infinity6b0-ssc009b.config

qodo-free-for-open-source-projects · 2026-09-11T18:38:11Z

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (1) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. Camera changes lack hardware proof 📘 Rule violation ☼ Reliability

Description

The shared HiSilicon and SigmaStar kernel configs disable storage, wireless, cryptographic, and
vendor modules—including CONFIG_RTL_CARDS and CONFIG_RTL8XXXU for every hi3518ev200 image—and
change FAT/VFAT linkage without before-and-after output from real cameras. Because these configs
feed lite and ultimate images across the affected families, the reported local clean-build and
image-size measurements leave boot, streaming, SD-card mounting, intended out-of-tree Wi-Fi loading,
and vendor-media operation after an upgrade unverified.

Code

br-ext-chip-hisilicon/board/hi3516cv200/hi3518ev200.generic.config[R1178-1179]
+# CONFIG_RTL_CARDS is not set
+# CONFIG_RTL8XXXU is not set

Evidence
PR Compliance ID 1 requires real-camera output for changes that can alter firmware behavior. The
changed HiSilicon config disables SCSI and in-tree Realtek support and makes FAT/VFAT built-in,
while the SigmaStar configs disable SCSI and vendor/crypto modules; the referenced defconfigs show
that these are shared kernel inputs for additional lite and ultimate targets beyond the three size
failures named in the PR. The supplied evidence reports only local builds and image-size
measurements, not camera boot, streaming, SD-card, Wi-Fi or module-loading, and vendor-media
results, demonstrating that the broader deployment surface has not been validated on hardware.
Rule 1: Hardware evidence is present and honest
br-ext-chip-hisilicon/board/hi3516cv200/hi3518ev200.generic.config[1178-1179]
br-ext-chip-hisilicon/board/hi3516cv200/hi3518ev200.generic.config[1038-1042]
br-ext-chip-hisilicon/board/hi3516cv200/hi3518ev200.generic.config[1998-2005]
br-ext-chip-hisilicon/configs/hi3518ev200_lite_defconfig[15-21]
br-ext-chip-hisilicon/configs/hi3518ev200_ultimate_defconfig[15-21]
br-ext-chip-sigmastar/board/infinity6b0/infinity6b0-ssc009a.config[1874-1881]
br-ext-chip-sigmastar/configs/ssc337_lite_defconfig[19-24]
br-ext-chip-sigmastar/configs/ssc335de_lite_defconfig[19-24]

Agent prompt

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

## Issue description
Shared kernel configurations remove or relink runtime capabilities in shipped HiSilicon and SigmaStar camera images without before-and-after evidence from real affected hardware. Local clean builds and image-size measurements do not establish that deployed cameras still boot and retain streaming, storage, networking, out-of-tree Wi-Fi loading, and vendor-media functionality.
## Fix Focus Areas
- br-ext-chip-hisilicon/board/hi3516cv200/hi3518ev200.generic.config[1038-1040]
- br-ext-chip-hisilicon/board/hi3516cv200/hi3518ev200.generic.config[1178-1179]
- br-ext-chip-hisilicon/board/hi3516cv200/hi3518ev200.generic.config[2001-2003]
- br-ext-chip-sigmastar/board/infinity6b0/infinity6b0-ssc009a.config[1003-1005]
- br-ext-chip-sigmastar/board/infinity6b0/infinity6b0-ssc009a.config[1877-1880]
- br-ext-chip-sigmastar/board/infinity6b0/infinity6b0-ssc009a.config[2310-2310]
- br-ext-chip-sigmastar/board/infinity6b0/infinity6b0-ssc009b.config[1003-1005]
- br-ext-chip-sigmastar/board/infinity6b0/infinity6b0-ssc009b.config[1877-1880]
- br-ext-chip-sigmastar/board/infinity6b0/infinity6b0-ssc009b.config[2310-2310]
## Recommended Fix
Restore the previous kernel settings until representative hi3518ev200 and Infinity6B0 cameras can be flashed and tested before and after the trim. Reapply the changes only after adding recorded real-hardware results to the PR description covering successful boot, streaming, SD-card mounting, intended out-of-tree Wi-Fi driver loading, vendor-media operation, kernel size, and rootfs size.

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

Tip of the day

💡 Did you know, you can switch off images and animations for a plain-text comment

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

qodo-free-for-open-source-projects · 2026-09-11T18:38:12Z

+# CONFIG_RTL_CARDS is not set
+# CONFIG_RTL8XXXU is not set


1. Camera changes lack hardware proof 📘 Rule violation ☼ Reliability

The shared HiSilicon and SigmaStar kernel configs disable storage, wireless, cryptographic, and vendor modules—including CONFIG_RTL_CARDS and CONFIG_RTL8XXXU for every hi3518ev200 image—and change FAT/VFAT linkage without before-and-after output from real cameras. Because these configs feed lite and ultimate images across the affected families, the reported local clean-build and image-size measurements leave boot, streaming, SD-card mounting, intended out-of-tree Wi-Fi loading, and vendor-media operation after an upgrade unverified.

Agent Prompt

## Issue description Shared kernel configurations remove or relink runtime capabilities in shipped HiSilicon and SigmaStar camera images without before-and-after evidence from real affected hardware. Local clean builds and image-size measurements do not establish that deployed cameras still boot and retain streaming, storage, networking, out-of-tree Wi-Fi loading, and vendor-media functionality. ## Fix Focus Areas - br-ext-chip-hisilicon/board/hi3516cv200/hi3518ev200.generic.config[1038-1040] - br-ext-chip-hisilicon/board/hi3516cv200/hi3518ev200.generic.config[1178-1179] - br-ext-chip-hisilicon/board/hi3516cv200/hi3518ev200.generic.config[2001-2003] - br-ext-chip-sigmastar/board/infinity6b0/infinity6b0-ssc009a.config[1003-1005] - br-ext-chip-sigmastar/board/infinity6b0/infinity6b0-ssc009a.config[1877-1880] - br-ext-chip-sigmastar/board/infinity6b0/infinity6b0-ssc009a.config[2310-2310] - br-ext-chip-sigmastar/board/infinity6b0/infinity6b0-ssc009b.config[1003-1005] - br-ext-chip-sigmastar/board/infinity6b0/infinity6b0-ssc009b.config[1877-1880] - br-ext-chip-sigmastar/board/infinity6b0/infinity6b0-ssc009b.config[2310-2310] ## Recommended Fix Restore the previous kernel settings until representative hi3518ev200 and Infinity6B0 cameras can be flashed and tested before and after the trim. Reapply the changes only after adding recorded real-hardware results to the PR description covering successful boot, streaming, SD-card mounting, intended out-of-tree Wi-Fi driver loading, vendor-media operation, kernel size, and rootfs size.

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

The rule is correctly applied here and I am not going to argue it away: this
changes what ships on a camera, so the template's exemption (docs, CI machinery,
repo metadata) does not cover it. I have no hi3518ev200 or Infinity6B0 unit on
the bench, which is why the PR body has a "Not tested on hardware" section rather
than a blank one.

For the record, what the change does rest on, so a reviewer can judge how much
the missing bench time is worth:

Each dropped symbol has a reason that is checkable from the tree rather than
from a measurement. SCSI: CONFIG_USB_STORAGE and CONFIG_ATA unset, no SCSI
low-level host driver enabled, CONFIG_MMC_BLOCK=y so cards arrive as
mmcblk. In-kernel Realtek: every wlandev profile serving hi3518ev200 in
general/overlay/etc/wireless/usb modprobes an out-of-tree 8188fu/8188eu,
and rtl8188fu-openipc/rtl8188eus-openipc are separate packages.
cryptodev/ms_notify/echainiv: absent from load_sigmastar's insmod list
and /etc/modules, unreferenced by any overlay script, and no string in
majestic, libmbedcrypto, curl or the mi_*/mhal vendor modules names
them.

FAT/VFAT are relinked, not removed: modules.builtin carries
fs/fat/fat.ko and fs/fat/vfat.ko in the built tree.

Clean from-scratch builds of both platforms, before and after. hi3518ev200
1776 -> 1795 KB kernel, 5144 -> 4944 KB rootfs, 63 -> 54 modules with
8188fu.ko, mac80211.ko and cfg80211.ko still present. Infinity6B0
2001 -> 1956 KB kernel, 5132 -> 5100 KB rootfs.

That establishes that nothing can load what was dropped; it does not establish
that a real camera boots and streams afterwards, which is the gap the rule is
about and which only a board can close.

So this should not merge on my say-so. Concretely it needs, on one hi3518ev200
and one Infinity6B0 camera, a sysupgrade from a current nightly to an image built
here plus: boot to SSH, RTSP streaming, an SD card mounting with FAT built in
(/proc/filesystems listing vfat with no module loaded), Wi-Fi associating via
the board's out-of-tree driver, and dmesg clean of new errors. I will add the
transcript to the PR body if someone with the hardware runs it, or fold in a
narrower version if a maintainer would rather split the Sigmastar half off.

Until then I would treat this as not ready rather than as waiting on a gate.

openipc-ai · 2026-09-11T18:46:01Z

CI has finished: all 14 firmware families build green, including the three that
are not the target of this change but share the touched directory
(hi3516cv200_lite, hi3516cv200_neo, and both ultimate variants), so there
is no collateral damage in the families that ride along.

The kernel sizes CI measured match my local clean builds exactly, which is worth
recording since the uImage side is the half that grows:

family	uImage (of 2048KB)	rootfs
`hi3518ev200_lite`	1795	4668 / 5120
`hi3518ev200_ultimate`	1795	6584 / 8192
`ssc333_lite`	1956	4824 / 5120
`ssc333_ultimate`	1956	5968 / 8192
`hi3516cv200_lite` (untouched config)	1657	4972 / 5120

1795 and 1956 are the same figures my local builds produced for the device
profiles in OpenIPC/builder, so the +19KB on HiSilicon and -45KB on Sigmastar
reproduce independently.

This still does not close the hardware gap above — it is evidence that the
change builds and that the partitions land where predicted, not that a camera
boots afterwards. Leaving the gate red for that reason.

openipc-ai · 2026-09-11T19:31:56Z

Merging on maintainer instruction with the hardware-evidence thread still open.

Recording that plainly rather than clearing the gate a way that would misstate
why: the skip-qodo-gate label is documented as a Qodo outage hatch and Qodo
was not down, and resolving the thread myself would assert a verification that
has not happened. This goes in as an admin override of branch protection, so the
unresolved finding stays visible in the record.

What is verified: every dropped symbol is unreachable by inspection of the tree
(argued in the PR body and the review thread), all 14 firmware families build
green in CI, and the kernel/rootfs sizes reproduce between CI and local clean
builds to the kilobyte.

What is not verified, and what someone with the hardware should still run —
on one hi3518ev200 and one Infinity6B0, sysupgrade from a nightly to an image
built from this commit, then check:

boot to SSH, and dmesg free of new errors;
RTSP streaming and /image.jpg returning 200;
an SD card mounting with FAT built in rather than modular —
/proc/filesystems should list vfat with no module loaded, and
modules.builtin should carry fs/fat/fat.ko and fs/fat/vfat.ko;
Wi-Fi associating through the board's out-of-tree 8188fu/8188eu;
the vendor media stack up (mi_*/mhal loaded, /dev/mmz* present).

If any of that fails, this is a clean revert — it is three kernel config files
and nothing else.

openipc-ai requested review from cronyx, flyrouter and viktorxda as code owners September 11, 2026 18:33

openipc-ai mentioned this pull request Sep 11, 2026

excludes: strip two sensors these boards cannot use, and a dead f2fs entry OpenIPC/builder#155

Open

qodo-free-for-open-source-projects Bot added the Compliance violation label Sep 11, 2026

qodo-free-for-open-source-projects Bot reviewed Sep 11, 2026

View reviewed changes

openipc-ai enabled auto-merge (squash) September 11, 2026 19:18

openipc-ai merged commit 38b75d2 into master Sep 11, 2026
30 of 36 checks passed

openipc-ai deleted the kernel-trim-hi3518ev200-ssc333 branch September 11, 2026 19:32

Navigation Menu

Uh oh!

Uh oh!

kernel: drop what no hi3518ev200 or ssc333 board can load, so the 8M lite boards fit again - #2399

kernel: drop what no hi3518ev200 or ssc333 board can load, so the 8M lite boards fit again#2399
openipc-ai merged 1 commit into
masterfrom
kernel-trim-hi3518ev200-ssc333

openipc-ai commented Sep 11, 2026

Uh oh!

qodo-free-for-open-source-projects Bot commented Sep 11, 2026

Uh oh!

qodo-free-for-open-source-projects Bot commented Sep 11, 2026 •

edited

Loading

Uh oh!

qodo-free-for-open-source-projects Bot Sep 11, 2026

Uh oh!

openipc-ai Sep 11, 2026

Uh oh!

openipc-ai commented Sep 11, 2026

Uh oh!

openipc-ai commented Sep 11, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Uh oh!

Conversation

openipc-ai commented Sep 11, 2026

What broke

What changes

Measured

Not tested on hardware

Uh oh!

qodo-free-for-open-source-projects Bot commented Sep 11, 2026

PR Summary by Qodo

Uh oh!

qodo-free-for-open-source-projects Bot commented Sep 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Code Review by Qodo

Uh oh!

qodo-free-for-open-source-projects Bot Sep 11, 2026

Choose a reason for hiding this comment

Uh oh!

openipc-ai Sep 11, 2026

Choose a reason for hiding this comment

Uh oh!

openipc-ai commented Sep 11, 2026

Uh oh!

openipc-ai commented Sep 11, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

qodo-free-for-open-source-projects Bot commented Sep 11, 2026 •

edited

Loading