Feat: Add support for the Mellow Fly C5 3D Printer board#9584
Conversation
deece
requested review from
a team,
AGM1968,
JohnTheCoolingFan,
PanderMusubi,
TheSnowfield,
Tonymac32,
chraac,
igorpecovnik,
janprunk,
krachlatte,
pyavitz,
schwar3kat,
sgjava and
teknoid
as code owners
📝 WalkthroughWalkthroughThis pull request adds complete support for the Mellow Fly-C5 board (Allwinner H618) across the Armbian build system, U-Boot bootloader, and Linux kernel. It includes board configuration files, device trees for two kernel versions, U-Boot defconfig and device tree patches, MMC driver improvements, H616 internal-EMAC networking patches, and wireless driver fixes. ChangesMellow Fly-C5 Board Support
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related PRs
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
github-actions
Bot
added
05
🚫 Missing required board assetsThis PR adds new board configuration(s). Required assets must already exist in github/armbian/armbian.github.io.
Missing items
Once the missing files are added (or a PR is opened in armbian/armbian.github.io), re-run this check. |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@config/boards/mellowflyc5.csc`:
- Around line 16-17: PACKAGE_LIST_BOARD currently enables Bluetooth packages for
mellowflyc5 though the device tree (sun50i-h618-mellow-fly-c5.dts) only
describes RTL8821CS SDIO Wi‑Fi and lacks any Bluetooth transport/serdev/UART
nodes; either remove "bluetooth" and "bluez-tools" from PACKAGE_LIST_BOARD in
mellowflyc5.csc to avoid shipping unnecessary BlueZ packages, or add the
appropriate Bluetooth transport/serdev DT nodes and UART bindings in the DTS
(the change must reference PACKAGE_LIST_BOARD and the
sun50i-h618-mellow-fly-c5.dts Bluetooth/serdev UART node definitions) so the
package list matches actual hardware support.
In `@patch/kernel/archive/sunxi-6.18/series.conf`:
- Line 561: In series.conf remove the single leading space before the tab on the
line containing "patches.armbian/add-mellowflyc5-to-allwinner-makefile.patch" so
the line begins with a tab only (matching surrounding entries); edit that
specific entry to align formatting with other lines to avoid parsing issues.
In `@patch/u-boot/u-boot-sunxi/board_mellowflyc5/0001-add-dts.patch`:
- Around line 22-30: U-Boot's new DTS selects emac0/ext_rgmii_phy with phy-mode
"rgmii-rxid" and PC=3.3V/PG=1.8V which conflicts with the kernel DTS that uses
emac1/RMII and PC=1.8V/PG=3.3V; pick the actual board wiring and make both
U-Boot and kernel DTS match: either change this patch's nodes (replace emac0 →
emac1, set phy-mode → "rmii", swap the PC/PG regulator references to match
1.8V/3.3V) or update the kernel DTs to use emac0/"rgmii-rxid" and
PC=3.3V/PG=1.8V; ensure the same regulator phandles (e.g., ®_dldo1) and the
ext_rgmii_phy property motorcomm,clk-out-frequency-hz are consistent across both
trees so Ethernet bring-up and IO-bank voltages are identical.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: d068140e-039d-4cde-9230-eee832c60d3e
📒 Files selected for processing (14)
config/boards/mellowflyc5.cscconfig/kernel/linux-sunxi64-current.configconfig/kernel/linux-sunxi64-edge.configlib/functions/compilation/patch/drivers_network.shpatch/kernel/archive/sunxi-6.18/dt_64/sun50i-h618-mellow-fly-c5.dtspatch/kernel/archive/sunxi-6.18/patches.armbian/add-mellowflyc5-to-allwinner-makefile.patchpatch/kernel/archive/sunxi-6.18/series.confpatch/kernel/archive/sunxi-6.19/dt_64/sun50i-h618-mellow-fly-c5.dtspatch/kernel/archive/sunxi-6.19/patches.armbian/add-mellowflyc5-to-allwinner-makefile.patchpatch/kernel/archive/sunxi-6.19/series.confpatch/misc/wireless-uwe5622/uwe5622-missing-prototypes.patchpatch/u-boot/u-boot-sunxi/board_mellowflyc5/0001-add-dts.patchpatch/u-boot/u-boot-sunxi/board_mellowflyc5/0002-add-defconfig.patchpatch/u-boot/u-boot-sunxi/board_mellowflyc5/0003-update-makefile.patch
| patches.armbian/drv-usb-gadget-composite-rename-serial-manufacturer.patch | ||
| patches.armbian/drv-video-st7796s-fb-tft-driver.patch | ||
| patches.armbian/include-uapi-drm_fourcc-add-ARM-tiled-format-modifier.patch | ||
| patches.armbian/add-mellowflyc5-to-allwinner-makefile.patch |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "Inspect exact whitespace around Line 561 (showing control chars):"
sed -n '556,565p' patch/kernel/archive/sunxi-6.18/series.conf | cat -A
echo
echo "Show mellowflyc5 entry in both series files with visible whitespace:"
rg -n 'add-mellowflyc5-to-allwinner-makefile\.patch' \
patch/kernel/archive/sunxi-6.18/series.conf \
patch/kernel/archive/sunxi-6.19/series.conf | cat -ARepository: armbian/build
Length of output: 822
Remove leading space before tab on Line 561.
Line 561 starts with a space followed by a tab, while all surrounding entries use only a tab. This inconsistency can cause parsing issues. Align with the standard format used elsewhere in the file.
Fix
- patches.armbian/add-mellowflyc5-to-allwinner-makefile.patch
+ patches.armbian/add-mellowflyc5-to-allwinner-makefile.patch🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@patch/kernel/archive/sunxi-6.18/series.conf` at line 561, In series.conf
remove the single leading space before the tab on the line containing
"patches.armbian/add-mellowflyc5-to-allwinner-makefile.patch" so the line begins
with a tab only (matching surrounding entries); edit that specific entry to
align formatting with other lines to avoid parsing issues.
|
@deece can this be completed?
|
|
Yup, I'll get back to this soon, I'm busy with tax returns at the moment, but I'm got other fixes in this series, like booting from emmc. Unfortunately progress is slow, as Mellow don't publish their device tree from Fly OS. |
|
Understand, no worries. If we are looking at standard support here https://docs.armbian.com/User-Guide_Board-Support-Rules/#standard-support then window is closing in two weeks else undefined. Take the time you need, no pressure. |
Add function prototypes to resolve compiler warnings and ensure correct linkage. Signed-off-by: Alastair D'Silva <alastair@d-silva.org>
igorpecovnik
added
08
🚫 Missing required board assetsThis PR adds new board configuration(s). Required assets must already exist in github/armbian/armbian.github.io.
Missing items
Once the missing files are added (or a PR is opened in armbian/armbian.github.io), re-run this check. |
There was a problem hiding this comment.
🧹 Nitpick comments (1)
config/boards/mellowflyc5.csc (1)
1-7: ⚡ Quick winAdd board lifecycle metadata (
INTRODUCEDand maintainer).Line 7 leaves
BOARD_MAINTAINERempty, andINTRODUCEDis missing. Adding both improves ownership and support tracking for this new board entry.Suggested patch
BOARD_NAME="Mellow Fly-C5" +INTRODUCED="2024" # set to actual first-ship year BOOTPATCHDIR="u-boot-sunxi" @@ -BOARD_MAINTAINER="" +BOARD_MAINTAINER="github-username"🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@config/boards/mellowflyc5.csc` around lines 1 - 7, Add lifecycle metadata by populating BOARD_MAINTAINER and adding an INTRODUCED field: set BOARD_MAINTAINER="Name <email@example.com>" (replace with the actual maintainer name and email) and add INTRODUCED="YYYY-MM-DD" or INTRODUCED="vX.Y" (use the project’s preferred date or version format) near the other board variables so the new board entry includes ownership and the introduction timestamp.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In `@config/boards/mellowflyc5.csc`:
- Around line 1-7: Add lifecycle metadata by populating BOARD_MAINTAINER and
adding an INTRODUCED field: set BOARD_MAINTAINER="Name <email@example.com>"
(replace with the actual maintainer name and email) and add
INTRODUCED="YYYY-MM-DD" or INTRODUCED="vX.Y" (use the project’s preferred date
or version format) near the other board variables so the new board entry
includes ownership and the introduction timestamp.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: c7b4ca22-c9b1-4d3e-a71b-9d6e25177678
📒 Files selected for processing (1)
config/boards/mellowflyc5.csc
| @@ -0,0 +1,5 @@ | |||
| verbosity=7 | |||
There was a problem hiding this comment.
Armbian default is 1. Why is 7 set here? If this is for debug purpose only, please revert.
There was a problem hiding this comment.
ah, that snuck through, I'll revert it
| # CONFIG_NET_VENDOR_WIZNET is not set | ||
| # CONFIG_NET_VENDOR_XILINX is not set | ||
| CONFIG_LED_TRIGGER_PHY=y | ||
| CONFIG_AC200_PHY=m |
There was a problem hiding this comment.
We had lots of trouble with phy on allwinner devices lately. It must be made sure this doesn't break any other boards (again).
There was a problem hiding this comment.
ha, I've spent weeks tearing my hair out trying to get this board to work since the move to 7.0. It turns out the mainline kernel didn't support the AC300 (a cutdown AC200), so I've included patches to get it working using the mainline drivers.
I don't have an AC200 machine to test with unfortunately, but I can roll some kernel packages to pass to someone who does.
There was a problem hiding this comment.
I recently tried to fix for the orangepizero2w ethernet hat (which also I believe uses the internal gmac of the soc) but failed because it broke phy on inovata quadra and since latter is an actually supported board I abandoned it. Perhaps this is a similar issue. LLM claims there are two drivers but the kernel binds to the wrong one and instead of failing over to the other it just uses it and fails.
Perhaps there's slop to it, did not go further. @igorpecovnik
#9815
There was a problem hiding this comment.
Here's my findings:
There are 2 MACs in the H618, the second is connected to the internal PHY. Some chips have a full AC200, and some have a cut down AC300.
There are 2 drivers now, an upstream driver, and the vendor driver. I assumed the preference would be to use an upstream driver where one exists.
The upstream driver is almost there with support for the AC300, I included a patch based on the reference manual for the AC300, along with some insights gained from pulling apart the binaries from FlyOS as well as the current state of the OpiZero2w board.
I haven't tested it on a chip with an AC200, but I would assume that since a driver has been upstreamed for it, it has been tested - the flow for the upstream driver speaking to an AC200 chip hasn't been touched.
The line above disables the vendor driver - there are a couple of lines further down that enable the upstream driver. Maybe the config can be patched in a board-specific way instead, if you want to be paranoid ;)
FYI, I had a look to see if I could buy a Quadra, it looks like Inovato shut down in 2024:
https://forum.inovato.com/post/inovato-update-13523982
There was a problem hiding this comment.
I assumed the preference would be to use an upstream driver where one exists.
Yes.
if I could buy a Quadra
Probably none of those boards / boxes are sold as new. This is old hardware. I will try to arrange one for you.
This adds baseline board support for the Mellow Fly-C5 (H618), including: - Board configurations and boot environment setup - ATF and U-Boot patches to redirect serial console to UART1 and enable eMMC in SPL - Common family adjustments to allow overriding bootenv file - Device tree, kernel configurations, and Ethernet controller patches. Note that the legacy vendor sunxi-gmac driver is dropped in favour of the mainline stmmac (dwmac-sun8i) driver. Signed-off-by: Alastair D'Silva <alastair@d-silva.org> Assisted-by: Antigravity <antigravity@google.com>
…imiting frequency Tune the eMMC (MMC2) clock frequency limit to achieve optimal throughput while maintaining 100% stability under 3.3V signaling. Bisection History (tested with default drive strength): | Configured Limit | Actual Clock Speed | Bus Width & Voltage | Stability Status | Read Performance | Write Performance | | :--- | :--- | :--- | :--- | :--- | :--- | | 20 MHz | 20 MHz | 8-bit DDR (3.3V) | Stable (0 errors) | 35.1 MB/s | - | | 35 MHz | 33.3 MHz | 8-bit DDR (3.3V) | Stable (0 errors) | 51.6 MB/s | - | | 40 MHz | 37.5 MHz | 8-bit DDR (3.3V) | Stable (0 errors) | 63.0 MB/s | 34.5 MB/s | | 42 MHz | 37.5 MHz | 8-bit DDR (3.3V) | Stable (0 errors) | 63.0 MB/s | 34.5 MB/s | | 45 MHz | 42.85 MHz | 8-bit DDR (3.3V) | Unstable (load) | 53.7 MB/s | - | | 48 MHz | 42.85 MHz | 8-bit DDR (3.3V) | Unstable (load) | 53.6 MB/s | - | | 52 MHz | 50.0 MHz | 8-bit DDR (3.3V) | Unstable (boot) | Failed | - | At clock frequencies above 37.5 MHz (e.g. 42.85 MHz, achieved via a 45 MHz or 48 MHz DTS limit), the eMMC link experiences silent transient transmission retries/errors, causing performance degradation before triggering critical I/O errors, filesystem corruption, or system crashes under sustained load. Limiting the eMMC max-frequency to 40 MHz (resulting in a 37.5 MHz actual clock) provides full reliability with 63.0 MB/s read and 34.5 MB/s write throughput. Signed-off-by: Alastair D'Silva <alastair@d-silva.org> Assisted-by: Antigravity <antigravity@google.com>
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (3)
config/boards/mellowflyc5.csc (1)
7-7: ⚡ Quick winSet a board maintainer to reduce orphaning risk.
BOARD_MAINTAINERis currently empty; please add at least one GitHub username.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@config/boards/mellowflyc5.csc` at line 7, The BOARD_MAINTAINER field is empty which risks orphaning; update the BOARD_MAINTAINER value to include at least one GitHub username (e.g. set BOARD_MAINTAINER="your-github-username" or a comma-separated list of usernames) so the maintainer is recorded; edit the BOARD_MAINTAINER entry in the mellowflyc5.csc file to replace the empty string with the appropriate GitHub handle(s).patch/kernel/archive/sunxi-7.0/patches.armbian/drv-net-stmmac-dwmac-sun8i-add-h616-internal-phy.patch (1)
9-13: 💤 Low valueSame style note as 6.18 version: extern declaration placement.
The extern declaration is placed between includes. Same cosmetic observation as the 6.18 patch.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@patch/kernel/archive/sunxi-7.0/patches.armbian/drv-net-stmmac-dwmac-sun8i-add-h616-internal-phy.patch` around lines 9 - 13, The extern declaration for sunxi_get_soc_chipid is incorrectly placed between `#include` directives; move or remove it so includes remain contiguous and place the extern after all `#include` statements or, better, add the prototype to an appropriate header and include that header; specifically adjust the extern int sunxi_get_soc_chipid(unsigned char *chipid); so it is not interleaved with `#include` <linux/io.h> and `#include` <linux/iopoll.h>, referencing the symbol sunxi_get_soc_chipid and the surrounding include block (linux/etherdevice.h, linux/io.h, linux/iopoll.h) when making the change.patch/kernel/archive/sunxi-6.18/patches.armbian/drv-net-stmmac-dwmac-sun8i-add-h616-internal-phy.patch (1)
9-13: 💤 Low valueConsider moving extern declaration after all includes.
The
extern int sunxi_get_soc_chipid(...)declaration is placed between include directives. Standard practice is to place extern declarations after all includes or in a shared header. This is cosmetic and doesn't affect functionality.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@patch/kernel/archive/sunxi-6.18/patches.armbian/drv-net-stmmac-dwmac-sun8i-add-h616-internal-phy.patch` around lines 9 - 13, Move the extern declaration for sunxi_get_soc_chipid out from between the `#include` lines and place it after the last `#include` (or, better, put it into a shared header if one exists); specifically, relocate the line "extern int sunxi_get_soc_chipid(unsigned char *chipid);" so all `#include` directives remain contiguous and the extern appears below them (or replace it with an appropriate header declaration).
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@config/boards/mellowflyc5.csc`:
- Around line 41-52: Remove the board-scoped function
custom_kernel_config__mellowflyc5 and any board-specific opts_* mutations
(opts_n, opts_m, opts_y and kernel_config_modifying_hashes entry) and instead
apply these kernel config changes in the appropriate family-scoped hook (e.g.,
the sun50iw9/LINUXFAMILY/BOARDFAMILY custom_kernel_config__) so the shared
kernel package expectations remain consistent; ensure the check for .config and
the display_alert logic are moved into that family-scoped function and that the
kernel_config_modifying_hashes string is updated there rather than at board
scope.
---
Nitpick comments:
In `@config/boards/mellowflyc5.csc`:
- Line 7: The BOARD_MAINTAINER field is empty which risks orphaning; update the
BOARD_MAINTAINER value to include at least one GitHub username (e.g. set
BOARD_MAINTAINER="your-github-username" or a comma-separated list of usernames)
so the maintainer is recorded; edit the BOARD_MAINTAINER entry in the
mellowflyc5.csc file to replace the empty string with the appropriate GitHub
handle(s).
In
`@patch/kernel/archive/sunxi-6.18/patches.armbian/drv-net-stmmac-dwmac-sun8i-add-h616-internal-phy.patch`:
- Around line 9-13: Move the extern declaration for sunxi_get_soc_chipid out
from between the `#include` lines and place it after the last `#include` (or,
better, put it into a shared header if one exists); specifically, relocate the
line "extern int sunxi_get_soc_chipid(unsigned char *chipid);" so all `#include`
directives remain contiguous and the extern appears below them (or replace it
with an appropriate header declaration).
In
`@patch/kernel/archive/sunxi-7.0/patches.armbian/drv-net-stmmac-dwmac-sun8i-add-h616-internal-phy.patch`:
- Around line 9-13: The extern declaration for sunxi_get_soc_chipid is
incorrectly placed between `#include` directives; move or remove it so includes
remain contiguous and place the extern after all `#include` statements or, better,
add the prototype to an appropriate header and include that header; specifically
adjust the extern int sunxi_get_soc_chipid(unsigned char *chipid); so it is not
interleaved with `#include` <linux/io.h> and `#include` <linux/iopoll.h>,
referencing the symbol sunxi_get_soc_chipid and the surrounding include block
(linux/etherdevice.h, linux/io.h, linux/iopoll.h) when making the change.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 4e768f2e-c775-49ab-8f51-c63896dd41c3
📒 Files selected for processing (14)
config/boards/mellowflyc5.cscconfig/bootenv/mellowflyc5.txtconfig/sources/families/include/sunxi64_common.incpatch/kernel/archive/sunxi-6.18/dt_64/sun50i-h618-mellow-fly-c5.dtspatch/kernel/archive/sunxi-6.18/patches.armbian/drv-net-stmmac-dwmac-sun8i-add-h616-internal-phy.patchpatch/kernel/archive/sunxi-6.18/patches.armbian/drv-net-stmmac-sun8i-add-h618-emac.patchpatch/kernel/archive/sunxi-6.18/series.confpatch/kernel/archive/sunxi-7.0/dt_64/sun50i-h618-mellow-fly-c5.dtspatch/kernel/archive/sunxi-7.0/patches.armbian/drv-net-stmmac-dwmac-sun8i-add-h616-internal-phy.patchpatch/kernel/archive/sunxi-7.0/patches.armbian/drv-net-stmmac-sun8i-add-h618-emac.patchpatch/kernel/archive/sunxi-7.0/series.confpatch/u-boot/u-boot-sunxi/board_mellowflyc5/0001-add-dts.patchpatch/u-boot/u-boot-sunxi/board_mellowflyc5/0002-add-defconfig.patchpatch/u-boot/u-boot-sunxi/board_mellowflyc5/0003-sunxi-mmc-Improve-reset-procedure-and-limit-emmc-frequency.patch
| function custom_kernel_config__mellowflyc5() { | ||
| # Always register the modification for hashing | ||
| kernel_config_modifying_hashes+=("mellowflyc5-ac200-md5") | ||
|
|
||
| if [[ -f .config ]]; then | ||
| display_alert "mellowflyc5" "Applying board-specific kernel configs" "info" | ||
| opts_n+=("AC200_PHY") | ||
| opts_m+=("MFD_AC200_SUNXI") | ||
| opts_m+=("AC200_PHY_SUNXI") | ||
| opts_y+=("CRYPTO_MD5") | ||
| fi | ||
| } |
There was a problem hiding this comment.
Remove board-scoped custom_kernel_config__*; this breaks shared-kernel contracts.
Kernel config is family-scoped in Armbian. Keeping per-board opts_* here can desync expectations from the shared sun50iw9 kernel package.
Suggested direction
-function custom_kernel_config__mellowflyc5() {
- # Always register the modification for hashing
- kernel_config_modifying_hashes+=("mellowflyc5-ac200-md5")
-
- if [[ -f .config ]]; then
- display_alert "mellowflyc5" "Applying board-specific kernel configs" "info"
- opts_n+=("AC200_PHY")
- opts_m+=("MFD_AC200_SUNXI")
- opts_m+=("AC200_PHY_SUNXI")
- opts_y+=("CRYPTO_MD5")
- fi
-}Based on learnings: kernel configuration is associated with LINUXFAMILY/BOARDFAMILY, and board-level custom_kernel_config__* causes inconsistency in shared kernel packages.
📝 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.
| function custom_kernel_config__mellowflyc5() { | |
| # Always register the modification for hashing | |
| kernel_config_modifying_hashes+=("mellowflyc5-ac200-md5") | |
| if [[ -f .config ]]; then | |
| display_alert "mellowflyc5" "Applying board-specific kernel configs" "info" | |
| opts_n+=("AC200_PHY") | |
| opts_m+=("MFD_AC200_SUNXI") | |
| opts_m+=("AC200_PHY_SUNXI") | |
| opts_y+=("CRYPTO_MD5") | |
| fi | |
| } |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@config/boards/mellowflyc5.csc` around lines 41 - 52, Remove the board-scoped
function custom_kernel_config__mellowflyc5 and any board-specific opts_*
mutations (opts_n, opts_m, opts_y and kernel_config_modifying_hashes entry) and
instead apply these kernel config changes in the appropriate family-scoped hook
(e.g., the sun50iw9/LINUXFAMILY/BOARDFAMILY custom_kernel_config__) so the
shared kernel package expectations remain consistent; ensure the check for
.config and the display_alert logic are moved into that family-scoped function
and that the kernel_config_modifying_hashes string is updated there rather than
at board scope.
There was a problem hiding this comment.
This is done to avoid breaking other boards still using the vendor driver instead of the upstream one
There was a problem hiding this comment.
@deece, understood — if other sun50iw9/H616 family boards still rely on a vendor out-of-tree AC200 driver (which conflicts with the upstream MFD_AC200_SUNXI/AC200_PHY_SUNXI modules), pushing these options into the family-level config would indeed break those boards. Isolating them in a board-scoped hook is a reasonable defensive choice in that case.
One thing worth adding is an in-code comment that explains why this is board-scoped rather than family-scoped, so the next reviewer doesn't question it the same way:
function custom_kernel_config__mellowflyc5() {
# Board-scoped intentionally: other sun50iw9/H616 boards still use the
# vendor out-of-tree AC200 driver. Promoting these to family-level config
# would break those boards, so we gate the upstream AC200 config here only.
kernel_config_modifying_hashes+=("mellowflyc5-ac200-md5")
...
}That makes the rationale self-documenting and future-proof.
✏️ Learnings added
Learnt from: deece
Repo: armbian/build PR: 9584
File: config/boards/mellowflyc5.csc:41-52
Timestamp: 2026-06-04T12:19:02.288Z
Learning: In config/boards/mellowflyc5.csc (Armbian build), the `custom_kernel_config__mellowflyc5()` function is board-scoped intentionally. It enables the upstream AC200 PHY driver options (`opts_n AC200_PHY`, `opts_m MFD_AC200_SUNXI`, `opts_m AC200_PHY_SUNXI`, `opts_y CRYPTO_MD5`). These are kept at board scope rather than sun50iw9/H616 family scope to avoid breaking other boards in the same family that still use the vendor out-of-tree AC200 driver. This is a deliberate exception to the general Armbian rule of keeping kernel config at LINUXFAMILY/BOARDFAMILY level.
Note: Learnings are effective only in the context of similar code segments. To apply general coding guidelines, please configure review instructions. You can manage existing learnings in the app.
🧠 Learnings used
Learnt from: igorpecovnik
Repo: armbian/build PR: 8849
File: config/boards/radxa-e54c.csc:14-28
Timestamp: 2025-11-02T20:49:56.719Z
Learning: In Armbian board configuration files (config/boards/*.conf, *.csc, etc.), do not use kernel_config_set, kernel_config_set_m, kernel_config_set_y, or custom_kernel_config__* functions to modify kernel configuration. Kernel configuration is associated with LINUXFAMILY/BOARDFAMILY, not individual BOARD. Board-specific kernel modifications cause inconsistency in kernel packages published to the apt repository because boards within a family share the same kernel packages. Kernel configuration changes must be made in the appropriate kernel config file (e.g., config/kernel/linux-*-*.config) or in family configuration files (config/sources/families/*.conf, *.inc) instead.
Learnt from: EvilOlaf
Repo: armbian/build PR: 9423
File: config/boards/dg-svr-865-tiny.conf:1-1
Timestamp: 2026-02-21T06:27:22.084Z
Learning: In Armbian board configuration files (config/boards/*.conf, *.csc, *.wip, etc.), always verify that the first line comment contains a proper hardware feature description rather than a description of what the file generates. The comment should include SoC model, core count, RAM options, and key features like connectivity options, storage interfaces, and special features. This is functionally important because the text is used during interactive compilation, not just for documentation. Flag any new board config files that have improper first-line comments (e.g., "# Generate kernel and rootfs image..." instead of "# Qualcomm QCS8250 octa core 4GB-16GB eMMC GBE USB3 WiFi BT").
<!-- </add_learning>
Learnt from: EvilOlaf
Repo: armbian/build PR: 8537
File: config/boards/qcom-robotics-rb5.conf:1-1
Timestamp: 2025-09-18T03:36:17.862Z
Learning: In Armbian board configuration files (regardless of file extension), the standard pattern is to have only one line as a comment describing the board hardware specifications. This single-line description typically includes the SoC model, core count, RAM options, and key features like connectivity options, storage interfaces, and special features. The file extensions indicate board support status: .conf (standard support), .csc (community supported), .eos (end of support), .tvb (tvbox), .wip (work in progress).
Learnt from: iav
Repo: armbian/build PR: 0
File: :0-0
Timestamp: 2026-05-08T21:08:19.635Z
Learning: In the Armbian build repository (https://github.com/armbian/build), the `setenv boot_interface ${devtype}` line inserted into `include/config_distro_bootcmd.h` in patch `patch/u-boot/v2026.04/board_helios4/0003-add-boot-marvell.cmd-backward-compatibility.patch` (lines 23-24) is board-specific code in a shared template. It is a straight port from v2025.10 carried unchanged into the v2026.04 bump (PR `#9786`). The proper fix — a Kconfig-gated `#ifdef CONFIG_TARGET_HELIOS4` guard or relocation into the Helios4 board-specific `bootcmd`/`preboot` — is explicitly deferred out of scope for the version-bump PR and left for a separate follow-up change.
Learnt from: juanesf
Repo: armbian/build PR: 9879
File: config/boards/radxa-cubie-a5e.csc:29-29
Timestamp: 2026-05-23T16:32:15.089Z
Learning: In `config/boards/radxa-cubie-a5e.csc`, the correct kernel module name for setting `aic_fw_path` via modprobe options is `aic8800_bsp` (not `aic8800_bsp_sdio`). Live-device dmesg from PR `#9879` confirms firmware loads correctly from `/lib/firmware/aic8800/SDIO/aic8800D80` using `options aic8800_bsp aic_fw_path=/lib/firmware/aic8800/SDIO/aic8800D80` in the modprobe config. Driver version: 2025_0926_91c9dae5-mm2.
Learnt from: HackingGate
Repo: armbian/build PR: 8665
File: config/boards/photonicat2.csc:4-4
Timestamp: 2025-10-26T10:41:35.118Z
Learning: In the Armbian build system, rk3576 boards consistently use BOARDFAMILY="rk35xx" for both vendor and edge kernel targets. The rk35xx family configuration sources rockchip64_common.inc, which provides edge and current kernel branch definitions, making these branches available even though they're not defined directly in rk35xx.conf.
Learnt from: EvilOlaf
Repo: armbian/build PR: 8537
File: config/boards/qcom-robotics-rb5.conf:1-1
Timestamp: 2025-09-18T03:36:17.862Z
Learning: In Armbian board configuration files, .wip and .conf extensions require BOARD_MAINTAINER to be present and contain at least one maintainer. If no maintainer is present, the board support rules state it does not qualify for standard support and must be moved to community support (.csc extension). This is documented at https://docs.armbian.com/User-Guide_Board-Support-Rules/
Learnt from: juanesf
Repo: armbian/build PR: 9874
File: config/boards/radxa-cubie-a5e.csc:10-10
Timestamp: 2026-05-21T17:51:42.869Z
Learning: In `config/boards/radxa-cubie-a5e.csc`, the `radxa-aic8800` extension is automatically disabled/skipped for kernel versions >= 6.20 via the `linux-version compare "${KERNEL_MAJOR_MINOR}" ge 6.20` guard in `post_install_kernel_debs__install_aic8800_dkms_package()` in `extensions/radxa-aic8800.sh`. A WIP patch with the AIC8800 driver for kernel 7.0 is in progress. This is intentional design — no manual intervention is needed when `KERNEL_TARGET` includes both `current` and `edge`.
Learnt from: juanesf
Repo: armbian/build PR: 9879
File: config/boards/radxa-cubie-a5e.csc:29-29
Timestamp: 2026-05-23T05:54:19.135Z
Learning: In `config/boards/radxa-cubie-a5e.csc` (Armbian build repo), the correct module name for modprobe options targeting the AIC8800 SDIO BSP module is `aic8800_bsp_sdio` (not `aic8800_bsp`). The `aic_fw_path` parameter is defined on `aic8800_bsp_sdio` and should point to `/lib/firmware/aic8800/SDIO/aic8800D80`. Live device dmesg confirmed that firmware loads from this path successfully when the option is set on `aic8800_bsp_sdio`.
Learnt from: tabrisnet
Repo: armbian/build PR: 0
File: :0-0
Timestamp: 2025-08-30T04:13:16.457Z
Learning: Armbian kernel configuration files like linux-filogic-current.config are autogenerated overlays on top of arch defconfig. Comments added manually will be lost during future updates by maintainers, and explicit "CONFIG_OPTION is not set" statements aren't needed for mutually exclusive options since these are overlay configs that only specify changes from the base configuration.
Learnt from: rpardini
Repo: armbian/build PR: 9159
File: patch/u-boot/u-boot-genio/0026-dts-configs-add-Grinn-GenioSBC-510.patch:161-161
Timestamp: 2026-01-03T20:46:29.189Z
Learning: For the Armbian genio family (config/sources/families/genio.conf and patch/u-boot/u-boot-genio/), when reviewing PRs that include vendor U-Boot patches from Collabora, avoid flagging potential issues in board configurations that are out of scope for the PR's primary focus (e.g., don't flag Genio 510/700 board issues when the PR is focused on radxa-nio-12l/Genio 1200). The maintainer prioritizes keeping vendor patches close to upstream for easier re-copying and maintenance, even if secondary board configs have potential mismatches.
<!-- </add_learning>
Learnt from: tabrisnet
Repo: armbian/build PR: 9136
File: lib/functions/compilation/armbian-kernel.sh:529-537
Timestamp: 2025-12-28T01:49:34.661Z
Learning: In lib/functions/compilation/armbian-kernel.sh's opts_m handling, checking .config (kernel defconfig) is problematic because savedefconfig elides options matching defconfig, making it impossible to distinguish overlay silence from defconfig agreement. The correct approach is to check only kernel_config_source_filename (the overlay) for explicit =y, otherwise default to =m, letting savedefconfig handle deduplication with defconfig automatically.
Learnt from: tabrisnet
Repo: armbian/build PR: 8678
File: config/kernel/linux-sunxi64-current.config:94-94
Timestamp: 2025-09-27T21:50:15.915Z
Learning: When kernel config files are generated through Armbian's automated process (previous config → armbian-kernel.sh changes → make oldconfig → Armbian machinery processing), manual config file edits are not appropriate since they would be overwritten. Deprecated option handling should be implemented in the automated tooling instead.
Learnt from: tabrisnet
Repo: armbian/build PR: 8661
File: lib/functions/compilation/armbian-kernel.sh:194-201
Timestamp: 2025-09-22T21:52:01.225Z
Learning: In lib/functions/compilation/armbian-kernel.sh, the kernel_config_modifying_hashes array is not universally required for all kernel configuration functions - some functions like armbian_kernel_config__netkit() operate without it, and adding entries with '=m' would be incorrect when the actual result might be '=y' for options already built-in.
Learnt from: EvilOlaf
Repo: armbian/build PR: 0
File: :0-0
Timestamp: 2025-08-02T05:46:10.664Z
Learning: In the Armbian build system, the modern recommended approach for kernel configuration is to use the kernel-config command via "./compile.sh BOARD=boardname BRANCH=branchname kernel-config" instead of the deprecated KERNEL_CONFIGURE=yes flag. This provides a two-step workflow: configure using menuconfig, then build, with better transparency and control over configuration changes.
Learnt from: adeepn
Repo: armbian/build PR: 9761
File: lib/functions/compilation/patch/drivers_network.sh:486-491
Timestamp: 2026-05-05T11:04:38.699Z
Learning: In armbian/build, the `driver_rtl88x2cs` function in `lib/functions/compilation/patch/drivers_network.sh` targets meson64 family boards and is intentionally kept without a `bleedingedge` branch exclusion. The commit reference is actively maintained by adeepn to track 7.1+ kernel compatibility. Unlike other out-of-tree drivers (rtl8189ES, rtl8189FS, rtl8723DS, rtl8852bs) which explicitly skip bleedingedge, rtl88x2cs is expected to build on bleedingedge (kernel 7.1) via upstream fixes in the jethome-iot/rtl88x2cs repository.
Learnt from: tabrisnet
Repo: armbian/build PR: 8913
File: config/sources/families/k3-beagle.conf:16-16
Timestamp: 2025-11-10T22:05:40.490Z
Learning: In the Armbian build system, kernel branches using non-mainline/vendor forks (like BeagleBoard's linux repository) should be named "vendor" or "vendor-rt" rather than "current" or "edge". The "current" and "edge" naming is reserved for mainline kernel branches. This affects both the case statement in family config files (e.g., `vendor | vendor-rt)` instead of `current | current-rt)`) and the corresponding KERNEL_TARGET declarations in board config files.
Learnt from: HeyMeco
Repo: armbian/build PR: 9707
File: extensions/radxa-aic8800.sh:51-55
Timestamp: 2026-04-21T22:01:17.922Z
Learning: In `extensions/radxa-aic8800.sh` (Armbian build system), the `update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-14 100` call inside the `RELEASE == "noble"` branch of `post_install_kernel_debs__install_aic8800_dkms_package()` is intentional. gcc-14 is deliberately left as the system-wide default compiler on Noble images so that future DKMS rebuilds (e.g. triggered by kernel upgrades on the running system) also use gcc-14. Do NOT flag this as leaving the alternative un-reverted or as an unintended side-effect.
Learnt from: amazingfate
Repo: armbian/build PR: 8595
File: lib/functions/compilation/patch/drivers_network.sh:0-0
Timestamp: 2025-09-09T07:30:22.419Z
Learning: RTW_WARN_LMT sed workaround in driver_rtl8852bs() function in lib/functions/compilation/patch/drivers_network.sh is necessary for kernel 6.1 compatibility, even when the upstream wifi-rtl8852bs driver has the macro defined for newer kernels. The workaround ensures cross-kernel compatibility from 6.1 to 6.16+.
Learnt from: rpardini
Repo: armbian/build PR: 8044
File: patch/u-boot/v2025.04/cmd-fileenv-read-string-from-file-into-env.patch:76-86
Timestamp: 2025-03-31T22:20:48.475Z
Learning: For the Armbian build project, maintaining consistency with existing patches across U-Boot versions (such as between 2025.01 and 2025.04) is prioritized over refactoring individual patches for code improvements.
Learnt from: iav
Repo: armbian/build PR: 0
File: :0-0
Timestamp: 2026-05-08T03:31:17.013Z
Learning: In the Armbian build repository (https://github.com/armbian/build), patches in `patch/u-boot/v2026.04/board_helios4/` were ported as-is from `patch/u-boot/v2025.10/board_helios4/`. The only functional change in PR `#9786` (helios4: bump u-boot to v2026.04) is updating `BOOTBRANCH` from `tag:v2025.10` to `tag:v2026.04` in `config/sources/families/include/mvebu-helios4.inc`. The patches themselves are not new development.
Learnt from: EvilOlaf
Repo: armbian/build PR: 0
File: :0-0
Timestamp: 2026-03-18T16:31:36.035Z
Learning: In patch files for the Armbian build system (e.g., patch/kernel/archive/sunxi-6.18/patches.armbian/), lines visible in a diff hunk that are prefixed with a space are context lines — they are unchanged surrounding content, not modifications introduced by the PR. Never describe context lines as additions or new code in summaries or reviews. Only lines with `+` or `-` prefixes represent actual changes. Misidentifying context lines as additions leads to incorrect summaries (e.g., falsely claiming a closing brace or `#endif` was "added" when it was already present).
Learnt from: EvilOlaf
Repo: armbian/build PR: 0
File: :0-0
Timestamp: 2025-12-19T13:56:45.124Z
Learning: When reviewing kernel or u-boot version bump PRs in the Armbian build system, check if patches existed in previous kernel version directories (e.g., sunxi-6.12, sunxi-6.13) before describing them as new features. If a patch and the majority of its contents existed previously with no major functionality changes, focus the review on the actual changes: the version bump itself and patch compatibility adjustments. Don't describe existing patches being ported/maintained across versions as new features or drivers—this is misleading. The patches are existing code being re-aligned to work with the new upstream version.
Learnt from: igorpecovnik
Repo: armbian/build PR: 9087
File: .github/workflows/pr-check-pictures.yml:138-146
Timestamp: 2025-12-16T13:40:07.649Z
Learning: In the Armbian build repository, when introducing new requirements or checks (like the board assets verification workflow), the project prefers an initial educational-only period where violations post helpful PR comments and warnings but don't block merges. This allows contributors to become familiar with new requirements before enforcement is enabled (typically after ~6 months).
Learnt from: ifroncy01
Repo: armbian/build PR: 9880
File: patch/u-boot/v2025.10/dt_upstream_rockchip/rk3588-easepi-r2.dts:7-11
Timestamp: 2026-05-25T04:20:10.712Z
Learning: In the Armbian build repo (PR `#9880`), the EasePi R2 board (`patch/u-boot/v2025.10/dt_upstream_rockchip/rk3588-easepi-r2.dts` and `patch/kernel/archive/rockchip64-6.18/dt/rk3588-easepi-r2.dts`) uses the full RK3588 SoC but intentionally includes `rk3588s.dtsi` (instead of `rk3588.dtsi`) because the hardware design does not implement the PCIe 3.0 x4 and SATA 3.0 interfaces that are unique to the full RK3588. This keeps the device tree clean and avoids defining unused nodes. The `compatible` string `"rockchip,rk3588"` is still correct since it reflects the physical SoC. This mismatch between include file (rk3588s.dtsi) and compatible string (rockchip,rk3588) is intentional and should not be flagged as an error.
Learnt from: EvilOlaf
Repo: armbian/build PR: 8428
File: config/boards/lckfb-taishanpi.csc:5-9
Timestamp: 2025-07-25T03:51:50.830Z
Learning: When reviewing PRs in the Armbian build system, U-Boot defconfig files and patches may be added as part of the PR changes but might not be visible in the current repository clone state during review. It's important to check the actual PR file changes directly via GitHub or the PR API to get the complete picture of what files are being added or modified.
Learnt from: EvilOlaf
Repo: armbian/build PR: 8428
File: config/boards/lckfb-taishanpi.csc:5-9
Timestamp: 2025-07-25T03:51:50.830Z
Learning: When reviewing PRs in the Armbian build system, U-Boot defconfig files and patches may be added as part of the PR changes but might not be visible in the current repository clone state during review. It's important to check the actual PR file changes directly via GitHub API (https://api.github.com/repos/armbian/build/pulls/{pr_number}/files) to get the complete picture of what files are being added or modified, especially for U-Boot patches that will be applied during the build process.
Learnt from: tabrisnet
Repo: armbian/build PR: 9275
File: patch/kernel/archive/filogic-6.18/frank-w/0053-net-phy-as21-try-the-driver-from-mtk-sdk.patch:1298-1326
Timestamp: 2026-01-19T22:46:53.605Z
Learning: In the Armbian build system, patches located under `patch/kernel/archive/filogic-6.18/frank-w/` are sourced from frank-w's out-of-tree BPI-Router-Linux repository (https://github.com/frank-w/BPI-Router-Linux) and are out of scope for code review. These patches are maintained externally and should not be reviewed in Armbian build PRs.
Learnt from: rpardini
Repo: armbian/build PR: 9119
File: config/boards/mixtile-core3588e.csc:1-1
Timestamp: 2025-12-28T15:39:55.793Z
Learning: In board configuration comments, e.g., a reference to Jetson SoM, treat it as indicating compatibility with the form factor/pin layout rather than implying the board uses an NVIDIA Jetson product. This helps reviewers avoid misclassifying boards as Jetson-based. Apply this understanding broadly to all .csc files under config/boards to ensure consistent interpretation of form-factor references.
There was a problem hiding this comment.
kernel customization on board level is not acceptable because it breaks repository. You cannot have for example multiple sunxi64-current kernel packages with the same version but different config. The only way to work around would be to introduce a new independent board family.
The correct approach would be take a deep dive into this network mess and fix this. However I don't find anyone is willing to do so.
On the bottom line new hw must not break existing one.
There was a problem hiding this comment.
Seems like the humans are having a chat. I'll hop back into my burrow for now. If you need me again, just tag @coderabbitai in a new comment, and I'll come hopping out!
There was a problem hiding this comment.
I'm happy to give it a go - is there one of these Inovato boards available that we can test the kernel on?
Can you provide more details on how it broke?
There was a problem hiding this comment.
is there one of these Inovato boards available that we can test the kernel on?
I have one somewhere but sadly no time to engage. There are others too, at least for two I know, but haven't hear from them in months. This problem is not related just to Innovato, but to other similar boards / tv boxes. Innovato has to work as is one of those that covers project bills.
There was a problem hiding this comment.
To break the dependency between boards, would the community be open to tweaking the infrastructure for a hierarchical kernel selection?
I'm thinking along the lines of, selecting the most specific kernel first if available, then going up the chain to more generic ones.
This would allow new drivers to be introduced as needed per platform, without risking existing boards - the maintainers could then test and update at their convenience, and once the community is happy for it to be accepted globally, it can be merged back into the family level kernel config.
There was a problem hiding this comment.
I'm currently looking to see if I can work around the conflicting drivers by having them both built as modules, and blacklisting the opposing module appropriately
It is already almost working that way: selecting the most specific kernel first (vendor and SOC patched mainline), where available, and then moving up the chain toward more generic ones (UEFI / generic arm64 with minimal patches). The real problem remains long term kernel maintenance. The sad reality is that the team doing the actual maintenance work - the regulars - is small. The broader "community" often comes in, adds support for their board, and then disappears when it is time to deal with the technical debt. That work then falls back on us, eventually becoming our personal time and financial expense. People like doing fun things for free. Hard, repetitive, never-ending maintenance work is much harder to attract. Allwinner stack is particularly messy, as we have been carrying many patches for years. Ideally, those patches would be cleaned up and mainlined. But who is going to do that work? At this point, I can do little more than keep pointing out the problem. Organizing work without people, time, or funding only extends the accumulated frustration // Rant mode off.
I do not think we are in a position to keep doing that anymore. Workarounds are exactly how we ended up here. The first step, among many, is to get the patch/code stack into a more manageable state. Once that happens, everything becomes much easier. |
I've spent the afternoon auditing the code, and I think my next push should provide a path forwards.
I've had kernel patches accepted before, so I know what's involved ;) |
3 participants
Description
This PR adds preliminary support for the Mellow Fly C5 3D Printer board. It will probably work for the C8P board too.
Note: EMMC, WiFi and Bluetooth are on the proprietary M2WE expansion board, containing an FN-Link 6221A-SRC (RTL8821CS) and a SiliconGo SGM8000C EMMC).
Documentation summary for feature / change
This will require documentation as a community supported platform.
See the above linked documentation for platform specifics.
How Has This Been Tested?
I have built Armbian Minimal Trixie Current & Edge and successfully booted the board, and accessed it over WiFi and ethernet. I have installed KlipperScreen and confirmed that the GUI lauches.
Checklist:
Summary by CodeRabbit
Release Notes
New Features
Bug Fixes