-
Notifications
You must be signed in to change notification settings - Fork 0
Expand file tree
/
Copy pathConfig.in
More file actions
165 lines (156 loc) · 8.55 KB
/
Copy pathConfig.in
File metadata and controls
165 lines (156 loc) · 8.55 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
menu "MiSTer external options"
menu "Realtek USB WiFi drivers (out-of-tree, P3.1)"
# MAINLINE-FIRST policy (ADR 0016). The rule is "use the in-kernel driver
# for every chip 6.18 can drive; keep an out-of-tree fork ONLY where
# mainline still has no USB driver". Applying it to today's kernel leaves
# exactly ONE fork ENABLED in the defconfig:
#
# rtl8852cu-morrownr -- RTL8852CU/RTL8832CU (Wi-Fi 6E). rtw89 has the
# 8852C chip HAL but only a PCIe bus file (rtw8852ce.c; there is no
# rtw8852cu.c), and RTW89_8852CE "depends on PCI" which this board has
# not got. No in-kernel driver exists for the chip at all.
#
# Every other package in this menu is sourced but left DISABLED in the
# defconfig, because mainline covers its chip and enabling both would
# bind-fight on the same USB IDs:
# 8188eu/8188fu/8710bu -> rtl8xxxu; 8821cu -> rtw88_8821cu;
# 8822bu -> rtw88_8822bu; 8812au -> rtw88_8812au;
# 8811au/8821au -> rtw88_8821au; 8814au -> rtw88_8814au
# (all in board/mister/de10nano/linux.config). They stay here, selectable,
# as a one-line-revert fallback if a mainline driver ever disappoints on
# specific hardware.
#
# rtl8188eu-aircrack-ng / rtl8821au-morrownr / rtl8821cu-morrownr are NOT
# named "rtl8188eu"/"rtl8821au"/"rtl8821cu" -- Buildroot upstream
# already ships its own same-named packages (different forks; re-confirmed
# present on the pinned tree 2026-07-25). Same name
# here would collide on both the Kconfig symbol and the Make namespace;
# see each package's Config.in for the detail. rtl8188fu/rtl8812au/rtl88x2bu
# have no such collision and keep the plain names; rtl8814au-morrownr and
# rtl8852cu-morrownr take the suffix purely for a uniform morrownr naming
# scheme (upstream has no rtl8814au or rtl8852cu package to collide with --
# re-checked against the pinned tree 2026-07-27).
source "$BR2_EXTERNAL_MISTER_PATH/package/rtl8188eu-aircrack-ng/Config.in"
source "$BR2_EXTERNAL_MISTER_PATH/package/rtl8188fu/Config.in"
source "$BR2_EXTERNAL_MISTER_PATH/package/rtl8812au/Config.in"
source "$BR2_EXTERNAL_MISTER_PATH/package/rtl8814au-morrownr/Config.in"
source "$BR2_EXTERNAL_MISTER_PATH/package/rtl8821au-morrownr/Config.in"
source "$BR2_EXTERNAL_MISTER_PATH/package/rtl8821cu-morrownr/Config.in"
source "$BR2_EXTERNAL_MISTER_PATH/package/rtl8852cu-morrownr/Config.in"
source "$BR2_EXTERNAL_MISTER_PATH/package/rtl88x2bu/Config.in"
endmenu
menu "USB controller drivers (out-of-tree, P3.2)"
# xow-firmware has its own "depends on BR2_PACKAGE_XONE", so it must be
# sourced after xone or menuconfig shows it (correctly) greyed out with
# no visible reason until xone is toggled on first -- order matters here
# only for menu readability, not for correctness.
source "$BR2_EXTERNAL_MISTER_PATH/package/xone/Config.in"
source "$BR2_EXTERNAL_MISTER_PATH/package/xow-firmware/Config.in"
endmenu
menu "Input-device userspace tooling"
# Deliberately NOT folded into the "USB controller drivers" menu above:
# everything there is an out-of-tree KERNEL MODULE, and these are plain
# userspace CLIs. Upstream Buildroot has neither package (checked against
# the pinned 2026.05.1 tree).
#
# This menu is for tools that reach input-device functionality the
# in-kernel drivers expose no interface for. It is NOT the place for
# anything that substitutes for a carried kernel patch -- the DualSense
# patches (0033/0037/0042) back Main_MiSTer's sysfs-LED and input-event
# ABIs, which no userspace process can serve. See
# docs/dualsense-tooling.md.
#
# Titled "Input-device", not "Controller": ltunify is about keyboards and
# mice on a Logitech receiver, and squeezing it under a gamepad-shaped
# heading would have been the wrong shape for the next tool too. Both
# entries satisfy the same one-line contract above; only the class of
# peripheral differs.
source "$BR2_EXTERNAL_MISTER_PATH/package/dualsensectl/Config.in"
# ltunify: pairing for Logitech Unifying/Nano receivers. hid-logitech-dj
# drives every ALREADY-paired device perfectly and has no interface for
# the pairing handshake itself -- there is no sysfs knob and no ioctl, so
# this is a genuine gap and not a duplicate of anything in the kernel.
# See docs/logitech-pairing.md.
source "$BR2_EXTERNAL_MISTER_PATH/package/ltunify/Config.in"
endmenu
menu "Firmware infra gap-fill (P3.3, P3.14)"
# Fills the handful of stock firmware.md entries that Buildroot's own
# linux-firmware package Config.in has no sub-option for, even though
# upstream linux-firmware ships them. See docs/firmware-parity.md.
source "$BR2_EXTERNAL_MISTER_PATH/package/linux-firmware-extra/Config.in"
# P3.14: Broadcom BCM20702 BT dongle firmware -- not in mainline
# linux-firmware; hash-pinned vendor firmware, same posture as xow
# (ADR 0003). See docs/firmware-parity.md.
source "$BR2_EXTERNAL_MISTER_PATH/package/bcm20702-firmware/Config.in"
endmenu
menu "MIDI / MT-32 (P3.8)"
# munt (mt32d) + MidiLink reproduce stock's MIDI/MT-32 softsynth stack;
# neither exists in upstream Buildroot. munt sourced first only for menu
# readability (midilink's help references it); both toggle independently.
# See docs/midi-mt32-parity.md.
source "$BR2_EXTERNAL_MISTER_PATH/package/munt/Config.in"
source "$BR2_EXTERNAL_MISTER_PATH/package/midilink/Config.in"
endmenu
menu "Main_MiSTer shared libraries"
# These back the Main_MiSTer shared-lib refactor (no task ID exists for
# this work -- it is referenced by name): Main_MiSTer stops vendoring
# lib/{lzma,zstd,miniz,libchdr} in its own tree and links Buildroot-
# provided shared libraries instead. Only half the refactor lives here:
# the upstream halves (zstd, minizip-ng) are plain Buildroot packages
# enabled straight from the defconfig; the two packages upstream Buildroot
# does not carry are the ones sourced in this menu. See
# docs/main-shared-libs.md for the full provider/SONAME map.
#
# lzma-sdk is sourced first because libchdr's Config.in selects
# BR2_PACKAGE_LZMA_SDK -- depended-on before dependent, the same
# menu-readability note as xone/xow-firmware above; both packages remain
# independently selectable.
source "$BR2_EXTERNAL_MISTER_PATH/package/lzma-sdk/Config.in"
source "$BR2_EXTERNAL_MISTER_PATH/package/libchdr/Config.in"
endmenu
menu "Archival / on-device update tooling"
# 7zip is upstream 7-Zip (`7zz`), sourced here rather than taken from
# upstream Buildroot because upstream Buildroot has NO 7zip package --
# only package/p7zip, the dead-since-2016 Unix port (re-confirmed absent
# on the pinned 2026.05.1 tree, 2026-07-27). It REPLACES the p7zip
# selection this image used to carry.
#
# It is in its own menu, not in "Main_MiSTer shared libraries" above,
# because it is neither a library nor Main_MiSTer's: its reason for
# existing is the UPDATE PATH. The static copy it drops in
# $(BINARIES_DIR)/7za ships on the exFAT data partition as
# /media/fat/linux/7za, displacing the p7zip 16.02 binary the Downloader
# otherwise fetches off the internet on first use. ADR 0023.
#
# NOTE the package dir/symbol start with a digit -- BR2_PACKAGE_7ZIP and
# the 7ZIP_ Make namespace. That is fine and has upstream precedent
# (package/4th -> BR2_PACKAGE_4TH, package/18xx-ti-utils ->
# 18XX_TI_UTILS_VERSION); pkg-generic's UPPERCASE derivation and GNU
# Make's variable naming both accept a leading digit. No collision with
# upstream's P7ZIP_ namespace either way.
source "$BR2_EXTERNAL_MISTER_PATH/package/7zip/Config.in"
endmenu
menu "Off-device backup"
# azcopy is Microsoft's Azure Storage CLI. Upstream Buildroot has no
# azcopy package (re-confirmed absent on the pinned 2026.05.1 tree,
# 2026-08-17 -- the only "az*" package there is azure-iot-sdk-c), so
# this tree authors one.
#
# Its own menu rather than a line in "Archival / on-device update
# tooling" above: that menu is about the UPDATE PATH -- 7zip exists to
# put a working `7za` at /media/fat/linux/7za so the Downloader never
# fetches a 2016 binary off the internet. azcopy is the opposite
# direction of travel, pushing the data partition OFF the board, and
# shares neither that menu's rationale nor its constraints.
#
# THE ONE THING TO KNOW BEFORE ENABLING IT: ~39 MiB installed, which
# makes it the second-largest package in this image (samba4, ~49 MiB,
# is first). docs/azcopy.md carries the measurement and the effect on
# the 15% free-space budget; docs/size-budget.md carries the budget.
#
# It is also the image's first and only Go package, so selecting it
# pulls host-go into the build. See package/azcopy/azcopy.mk for what
# that costs and why host-go is left at its from-source default.
source "$BR2_EXTERNAL_MISTER_PATH/package/azcopy/Config.in"
endmenu
endmenu