#61 asks for 8812eu support on gk7205v200 FPV. #70 and the first version of this PR
both tried to satisfy it by adding BR2_PACKAGE_RTL88X2EU_OPENIPC=y next to the existing
BR2_PACKAGE_RTL8812AU_OPENIPC=y. CI built that and it does not fit:
- uImage: [1988KB/2048KB]
- rootfs.squashfs: [5504KB/5120KB]
-- size exceeded by: 384KB
Two heavy kernel Wi-Fi drivers do not go in one 8M image. The driver itself is fine --
8812eu.ko links and installs -- it is purely flash budget, and there is no 384KB of
slack in a 5MB rootfs that was already at its cap.
The tree had already said so. Every defconfig here that ships both drivers is 16M: the
ssc338q, ssc30kq, ssc377qe and ssc378qe fpv/apfpv/rubyfpv targets. Every 8M one ships
8812au alone: gk7205v200/v210/v300 fpv and venc, hi3516ev200_fpv, hi3516ev300_fpv. The
"missing" 8812eu on the Goke configs was never an oversight; it is what 8M allows.
So this is a separate build. gk7205v200_fpv_8812eu is gk7205v200_fpv with one line
changed, the driver swapped rather than added:
-BR2_PACKAGE_RTL8812AU_OPENIPC=y
+BR2_PACKAGE_RTL88X2EU_OPENIPC=y
The existing gk7205v200_fpv is untouched, so nobody on an 8812au adapter is affected.
It builds with room to spare -- rootfs 5024KB/5120KB, 96KB headroom.
Nothing else had to move for it:
- Registration is automatic; the defconfig is the registration. --self-test passes at
108 devices and the diff narrows to exactly this target, so its own build proved it.
- Excludes resolve as ${OPENIPC_SOC_MODEL}_${OPENIPC_VARIANT}.list in firmware's
rootfs_script.sh, and VARIANT stays "fpv", so it reuses gk7205v200_fpv.list. That
list strips neither driver.
- Release assets do not collide. master.yml keys on the underscore count:
gk7205v200_fpv is COMMON=1 and uploads the canonical openipc.gk7205v200-nor-fpv.tgz,
this one is COMMON=2 and is renamed to gk7205v200_fpv_8812eu-nor.tgz. Same for its
sizes.json.
Only gk7205v200, which is what #61 asked for. The other four 8M FPV targets have the
same constraint and could take the same treatment if anyone asks.
Closes#70.
builder.sh copies devices/<item>/* over the firmware checkout before make, so a
device directory that carries its own board .config replaces firmware's copy
outright. OpenIPC/firmware #2308 and #2309 turned CONFIG_VT and CONFIG_INPUT off
across the fleet; the 13 board configs here were never touched by that, so 21
device builds carried on shipping the virtual-terminal layer -- /dev/tty0,
/dev/tty1..63, the keyboard translation tables, console selection and screen
code -- for a monitor and keyboard no camera has. flyrouter pointed this gap out
on #2308.
The transformation is not re-derived here. For each file the symbol-level delta
was taken straight out of firmware's history (85233f0e^..HEAD) for the config it
shadows and replayed, so these land on exactly the state that was reviewed and
proven on hardware there. Every affected symbol in every copy still held
firmware's pre-sweep value, so nothing here was a deliberate customisation --
they were simply stale.
Eleven of the thirteen also needed CONFIG_EXPERT=y first. In drivers/tty/Kconfig
the symbol reads
config VT
bool "Virtual terminal" if EXPERT
select INPUT
default y
so its prompt exists only under EXPERT, and without it olddefconfig finds the
symbol invisible and forces it back to its default -- "# CONFIG_VT is not set"
on its own does nothing.
Two exceptions:
* gk7102c keeps CONFIG_INPUT. It sets CONFIG_INPUT_EVDEV=y and firmware's
gk710x, which it shadows, keeps INPUT for the same reason. Only VT moves.
* CONFIG_INPUT_LEDS=m is dropped on the six FPV/OTG copies. It is the
input-to-LED bridge, lives inside `if INPUT`, and firmware never carried it,
so olddefconfig would have dropped it silently -- stated here so the file
matches the kernel it generates. CONFIG_LEDS_CLASS is a separate symbol in
drivers/leds and is untouched: the FPV status LEDs are unaffected.
Nothing consumes VT on any of these. FRAMEBUFFER_CONSOLE is its only in-kernel
consumer and no config in this repository sets it at =y or =m, so the sole
console driver compiled in was DUMMY_CONSOLE and writes to /dev/tty0 went
nowhere. The ingenic t21/t31/t40 copies already matched firmware -- VT off,
INPUT kept for their GPIO keys -- and are left alone.
Verified by generating the kernel config the way builder.sh does: copy
devices/common over a firmware checkout at master and run the configure step,
before and after. gk7205v200_fpv, comparing the two generated
build/linux-custom/.config files symbol by symbol:
turned OFF (8) CONSOLE_TRANSLATIONS DUMMY_CONSOLE HW_CONSOLE INPUT
INPUT_LEDS VT VT_CONSOLE VT_CONSOLE_SLEEP
turned ON (1) EXPERT
value changed none
LEDS_CLASS=m, TTY, UNIX98_PTYS, SERIAL_AMBA_PL011_CONSOLE, USB_GADGET,
CFG80211, MAC80211, KALLSYMS, COREDUMP, NAMESPACES, ELF_CORE,
CORE_DUMP_DEFAULT_ELF_HEADERS, DEBUG_KERNEL, DEBUG_MEMORY_INIT: unchanged.
That last line is the check #2308 missed on its first pass: EXPERT carries
`select DEBUG_KERNEL` and unhides a block of on-by-default options, which there
silently moved COREDUMP and friends. DEBUG_KERNEL was already y in these
configs, so nothing else moved.
Building the kernel both ways in that same tree, on the OpenIPC/linux goke
tarball these devices use:
gk7205v200_fpv uImage 2071368 -> 2036040 -35328 bytes (-1.71%)
zImage 2058872 -> 2023544 -35328 bytes (-1.72%)
which lines up with the -34680 bytes firmware measured on gk7205v200_lite for
the same delta. drivers/input/input-leds.ko is built in the before tree and is
not built after.
OpenIPC/firmware dropped BR2_PACKAGE_JSONFILTER from every one of its
defconfigs in #2304, once the WebUI stopped calling it. builder's defconfigs are
its own files, so 97 of them kept selecting it. jsonfilter selects JSON_C and
LIBUBOX, and on a device that enables neither uqmi-openipc nor wifibroadcast-ng
nothing else selects libubox, so it and jsonfilter shipped for nothing.
That is what has had three devices over their rootfs cap:
hi3518ev200_lite_switcam-hs303 rootfs 5124KB/5120KB -4KB
ssc333_lite_babysense-see-hd-ip206 rootfs 5124KB/5120KB -4KB
ssc333_lite_meari-speed-6s rootfs 5128KB/5120KB -8KB
all three red on the nightly, meari since 2026-08-24. Bisecting meari across
firmware revisions lands on #2301, which added 408 bytes to the comment-stripped
sysupgrade script -- these images had no headroom left at all, and 408 bytes of
a genuine bug fix was enough to push one over a 4KB padding step. The fix is to
give them headroom, not to give back the bug fix.
Measured on ssc333_lite_meari-speed-6s, built the way builder.sh builds it --
devices/<item>/ copied over a firmware checkout at master, clean tree both times:
before rootfs.squashfs 5128KB/5120KB size exceeded by: 8KB
after rootfs.squashfs 5096KB/5120KB 24KB spare
-32KB, from /usr/bin/jsonfilter (18068 raw) and /usr/lib/libubox.so (30404 raw).
json-c does NOT go: majestic lists it in MAJESTIC_DEPENDENCIES, so buildroot
builds and installs it whether or not BR2_PACKAGE_JSON_C is set. Only the two
files above leave the image.
Two consumers genuinely need jsonfilter and both keep it:
* devices/apfpv's own etc/init.d/S99msposd reads majestic's config.json
through it, and ssc338q_apfpv and ssc378qe_apfpv do not enable
wifibroadcast-ng. Those two keep the symbol, with the reason written above
the line -- the same undeclared-runtime-dependency trap firmware #2305 had
to fix, and the reason this is 95 defconfigs and not 97.
* every other FPV device enables wifibroadcast-ng, whose Config.in selects
BR2_PACKAGE_JSONFILTER (added by #2305) for the same script. They keep it
without saying so.
LTE devices keep libubox through uqmi-openipc, which selects it independently.
Nothing else in this repository calls jsonfilter: grepping devices/ and
package/ finds only that one S99msposd line, and firmware's own tree has no
caller left outside wifibroadcast-ng.
Enable the media / V4L2 / uvcvideo kernel stack so a USB camera exposes
/dev/videoN for majestic's usbcam second-camera path.
To fit the 8M NOR (2M kernel / 5M rootfs) without dropping any sensor
library, uvcvideo and the videobuf2 framework are built INTO the kernel
(=y) instead of shipped as rootfs modules: the kernel partition had ~55 KB
of spare room while the rootfs was tight, so ~44 KB of weight moves from
rootfs to kernel. Resulting images: uImage 2022.8 KB / 2048 KB (25 KB
spare), rootfs squashfs 5080 KB / 5120 KB (40 KB spare).
GSPCA -- a separate driver for non-UVC webcams, pulled in by "default m
depends on VIDEO_V4L2" -- is disabled.
No kernel patch is carried: mmap capture works on stock uvcvideo once
majestic aligns its mmap() prototype with this MMAP_MUSL build's
uint32_t-offset shim (a userspace fix), so the earlier read()/fileio
uvcvideo patch is not needed.
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
OpenIPC/firmware PR #2162 (merged 2026-05-30) dropped the legacy
BR2_TOOLCHAIN_EXTERNAL_GCC_8=y + BR2_GCC_VERSION_LEGACY=y block from
its 18 ARM defconfigs and ships gcc 13.3.0 to those platforms now.
OpenIPC/builder's per-device and common Goke defconfigs still pinned
gcc 8, so every Goke job in the 2026-06-02 nightly Build run failed at
the toolchain stage with:
Incorrect selection of gcc version: expected 8.x, got 13.3.0
make[1]: *** [toolchain-external-custom/.stamp_configured] Error 1
Mirror #2162 across the 24 affected defconfigs (8 common + 16
per-device). No other defconfig content changes.
Unrelated 4 Sigmastar rootfs-overflow failures in the same nightly are
tracked separately.
Fixes failing run: https://github.com/OpenIPC/builder/actions/runs/26804792607
Co-authored-by: John <zekccsripfwrocp-15689@yn.furvionx.com>
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Add BR2_PACKAGE_HISILICON_OPENSDK=y to 9 hi3516cv200-family profiles
that were missing it. These boards will now get open_ modules built
from openhisilicon source instead of vendor-only blobs from osdrv.
Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
