Add Support Shimeta Aiot-rk3588a #8971
Draft
+729
−0
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Contributor
|
Important Review skippedDraft detected. Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the WalkthroughA new board configuration is introduced for the Shimeta AIoT RK3588 platform. Three files establish support for this board: a configuration file with build parameters, a U-Boot defconfig enabling hardware and boot features, and a device tree source specifying hardware peripherals. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes
Suggested reviewers
Poem
Pre-merge checks and finishing touches✅ Passed checks (3 passed)
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 |
Contributor
Hey @ghhccghk! 👋Thanks for submitting your first pull request to the Armbian project — we're excited to have you contributing! 🧡 If you'd like to stay informed about project updates or collaborate more closely with the team, Also, don’t forget to ⭐ star the repo if you haven’t already — and welcome aboard! 🚀 |
github-actions
bot
added
size/large
tabrisnet
requested changes
Nov 20, 2025
| CONFIG_DM_ETH_PHY=y | ||
| CONFIG_DWC_ETH_QOS=y | ||
| CONFIG_GMAC_ROCKCHIP=y | ||
| CONFIG_NVME=y |
Collaborator
There was a problem hiding this comment.
https://shimetadevice.com/wp-content/uploads/2025/06/Motherboard-AIoT-3588A-V1.0-Specifications-V1.pdf doesn't mention a slot for an SSD. It does have a B-key M.2 slot [intended for LTE/5G connectivity], but typically B-key [or B+M] SSDs are SATA, which probably isn't wired to this slot [the datasheet doesn't give a pinout]. B-key NVMe SSDs exist but seem to be uncommon in that I can't find them for sale in the obvious corners.
Should you be enabling CONFIG_CMD_SATA & CONFIG_SATA for the SATA port it has?
@coderabbitai
Contributor
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Check the datasheet URL to understand hardware capabilities
echo "=== Checking datasheet availability ==="
curl -sI "https://shimetadevice.com/wp-content/uploads/2025/06/Motherboard-AIoT-3588A-V1.0-Specifications-V1.pdf" | head -20
echo -e "\n=== Search for SATA configuration in other RK3588 defconfigs ==="
fd -e defconfig . patch/u-boot/legacy/u-boot-radxa-rk35xx/defconfig/ --exec grep -l "CONFIG_SATA"
echo -e "\n=== Check what SATA options are in RK3588 defconfigs ==="
fd -e defconfig . patch/u-boot/legacy/u-boot-radxa-rk35xx/defconfig/ --exec grep -H "CONFIG.*SATA"
echo -e "\n=== Check for NVME in other RK3588 defconfigs ==="
fd -e defconfig . patch/u-boot/legacy/u-boot-radxa-rk35xx/defconfig/ --exec grep -H "CONFIG_NVME"
echo -e "\n=== Search for board mentions in the codebase ==="
rg -i "aiot.*3588" --type-add 'conf:*.{conf,csc,inc}' --type conf -C2
echo -e "\n=== Check for board config file ==="
fd -i aiot config/boards/
Length of output: 1401
🏁 Script executed:
#!/bin/bash
echo "=== Board config file content ==="
cat config/boards/shimeta-aiot-rk3588a.conf
echo -e "\n=== List all defconfigs in this u-boot directory ==="
fd -e defconfig . patch/u-boot/legacy/u-boot-radxa-rk35xx/defconfig/ -x basename
echo -e "\n=== Check a few other RK3588 defconfigs for storage options ==="
for config in rock-5b-rk3588_defconfig rock-5a-rk3588_defconfig orangepi-5-rk3588s_defconfig; do
if [ -f "patch/u-boot/legacy/u-boot-radxa-rk35xx/defconfig/$config" ]; then
echo -e "\n--- $config storage configs ---"
grep -E "CONFIG_(NVME|SATA|MMC|MTD)" "patch/u-boot/legacy/u-boot-radxa-rk35xx/defconfig/$config" | head -20
fi
done
echo -e "\n=== Check for device tree files for aiot ==="
fd -i aiot patch/
echo -e "\n=== Search for SATA-related configs in all u-boot patches ==="
rg -i "CONFIG_SATA" patch/u-boot/legacy/u-boot-radxa-rk35xx/ -l
echo -e "\n=== Check if SATA is mentioned anywhere in rockchip u-boot context ==="
rg "CONFIG_SATA" patch/u-boot/ --type-add 'config:defconfig' --type config -C1 | head -50
Length of output: 1063
🏁 Script executed:
#!/bin/bash
echo "=== Search for SATA configs in all u-boot patches ==="
rg "CONFIG_SATA" patch/u-boot/ -l | head -20
echo -e "\n=== Check for AHCI/SATA drivers in u-boot patches ==="
rg "CONFIG.*AHCI" patch/u-boot/legacy/ --type-add 'config:defconfig' --type config | head -30
echo -e "\n=== Look for SATA in other u-boot trees ==="
fd defconfig patch/u-boot/v2024.10/ --exec grep -l "CONFIG_SATA" 2>/dev/null | head -10
echo -e "\n=== Check what SATA options exist in a board with SATA ==="
if fd defconfig patch/u-boot/v2024.10/ --exec grep -l "CONFIG_SATA" 2>/dev/null | head -1 | xargs -I {} bash -c "test -f {} && grep -E 'CONFIG.*SATA|CONFIG.*AHCI' {} | head -20"; then
echo "Found SATA configs"
else
echo "Checking legacy trees..."
rg "CONFIG_(SATA|AHCI)" patch/u-boot/legacy/ --type-add 'config:defconfig' --type config -m1 -C5
fi
echo -e "\n=== Check RK3588 AHCI/SATA support ==="
rg -i "ahci|sata" patch/kernel/rockchip-rk3588/ --type dts -C2 | head -50
Length of output: 596
🏁 Script executed:
#!/bin/bash
echo "=== Check bananapi SATA patch ==="
cat patch/u-boot/v2025.01/board_bananapicm4io/003-configs-bananapi-cm4-cm4io_defconfig-sata-support.patch
echo -e "\n=== Check radxa station-m2 SATA config ==="
grep -A10 -B10 "SATA" patch/u-boot/u-boot-radxa-latest/board_station-m2-rk3566_defconfig.patch | head -30
echo -e "\n=== Check if RK3588 has AHCI/SATA controller support ==="
rg -i "sata|ahci" patch/kernel/rockchip-rk3588-vendor/ -g "*.dts*" -C2 | head -60
echo -e "\n=== Check device tree reference in board config ==="
cat config/boards/shimeta-aiot-rk3588a.conf | grep DTB
echo -e "\n=== Look for that specific dtb ==="
fd "rk3588-evb7" patch/
Length of output: 2588
🏁 Script executed:
#!/bin/bash
echo "=== Check for RK3588 SATA/AHCI support in vendor kernel patches ==="
fd . patch/kernel/rockchip-rk3588-vendor-6.1/ -t d | head -1
if [ -d "patch/kernel/rockchip-rk3588-vendor-6.1/" ]; then
rg -i "sata|ahci" patch/kernel/rockchip-rk3588-vendor-6.1/ -g "*.dts*" -C1 | head -40
fi
echo -e "\n=== Check RK3588 family config for SATA mentions ==="
rg -i "sata" config/sources/families/rockchip-rk3588.conf
echo -e "\n=== Verify board description comment ==="
head -1 config/boards/shimeta-aiot-rk3588a.conf
Length of output: 359
@tabrisnet You're absolutely correct! Based on the hardware specifications you reviewed and my analysis of the codebase:
Current Issues:
- CONFIG_NVME=y (Line 143) is incorrectly enabled - the board doesn't have an NVMe-capable M.2 slot
- Missing SATA support - the board has a SATA port but no SATA configuration
- Incorrect board description -
config/boards/shimeta-aiot-rk3588a.confincorrectly claims "NvME" support in the comment
Recommended Changes:
For the U-Boot defconfig patch/u-boot/legacy/u-boot-radxa-rk35xx/defconfig/aiot_rk3588a_defconfig:
Remove:
CONFIG_NVME=y
Add: (following the pattern from other boards like Station M2 and BananaPi CM4)
CONFIG_SATA=y
CONFIG_CMD_SATA=y
CONFIG_SCSI=y
CONFIG_DM_SCSI=y
CONFIG_SCSI_AHCI=y
CONFIG_AHCI_PCI=y
Additionally, the board description comment in config/boards/shimeta-aiot-rk3588a.conf should be updated from:
#Rockchip RK3588 SoC octa core 4-16GB SoC 2.5GBe PoE eMMC USB3 NvME
to:
#Rockchip RK3588 SoC octa core 4-16GB SoC 2.5GBe PoE eMMC USB3 SATA
This will properly enable SATA support for the board's actual hardware capabilities.
🧠 Learnings used
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: igorpecovnik
Repo: armbian/build PR: 8789
File: config/kernel/linux-sunxi64-edge.config:839-839
Timestamp: 2025-10-22T07:51:53.015Z
Learning: In Armbian's wireless driver configuration, CONFIG_RK_WIFI_DEVICE_* options are Rockchip-specific device registration settings, while CONFIG_WLAN_UWE* are the actual cross-platform driver modules for UWE5622 wireless chips. The UWE5622 chip (manufactured by Unisoc/Spreadtrum) is used on multiple Allwinner boards including Orange Pi Zero 2/2W/3 and Orange Pi 3 LTS, so CONFIG_WLAN_UWE5621/5622 along with Unisoc infrastructure options (CONFIG_SPARD_WLAN_SUPPORT, CONFIG_SC23XX, CONFIG_UNISOC_WIFI_PS, CONFIG_WCN_BSP_DRIVER_BUILDIN) are correct in sunxi64 kernel configs.
Learnt from: amazingfate
Repo: armbian/build PR: 8619
File: config/sources/families/rockchip.conf:222-230
Timestamp: 2025-09-14T06:32:29.806Z
Learning: In the Armbian build system, the write_uboot_platform() function implementations follow different patterns across Rockchip family files. The newer standard (used in rockchip64_common.inc and rk3506) includes 'status=none' parameter in dd commands, while older implementations (rk3288, rk322x) use an older pattern without this parameter. The rk3506 implementation correctly follows the current Rockchip family standard.
Learnt from: amazingfate
Repo: armbian/build PR: 8619
File: config/sources/families/rockchip.conf:64-70
Timestamp: 2025-09-14T06:29:18.958Z
Learning: In the Armbian build system, vendor branch configurations in family files are designed to be shared across multiple SoCs within the same family that use the same vendor kernel tree. For example, rk35xx and rockchip-rk3588 families both use identical vendor branch settings (same KERNELSOURCE, KERNELBRANCH, and KERNELPATCHDIR), demonstrating that vendor branches are intentionally generic rather than SoC-specific.
Learnt from: pyavitz
Repo: armbian/build PR: 8421
File: config/kernel/linux-sunxi64-edge.config:805-825
Timestamp: 2025-07-27T15:53:30.629Z
Learning: In the Armbian build system, kernel configurations prioritize broad hardware compatibility over optimization concerns. Even when including numerous legacy/obsolete drivers causes technical issues like increased initramfs size and slower enumeration, the project philosophy is to "appease the masses" by ensuring maximum device compatibility rather than optimizing for specific use cases.
Learnt from: EvilOlaf
Repo: armbian/build PR: 8619
File: config/sources/families/rockchip.conf:64-70
Timestamp: 2025-09-14T06:10:25.610Z
Learning: In the Armbian build system, rk32xx and rk33xx Rockchip SoCs no longer have BSP-based (vendor) kernel branches. The rk3506 is the first 32-bit Rockchip SoC to use the vendor branch in the current codebase.
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: 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: 8886
File: patch/kernel/rk35xx-vendor-6.1/dt/rk3528-nanopi-rev01.dts:9-9
Timestamp: 2025-11-08T06:39:24.527Z
Learning: In Armbian's Rockchip vendor kernel branches (rk35xx-vendor), device tree files may not require the same headers as mainline Linux. For example, input key definitions like KEY_BACK and KEY_VOLUMEUP may be handled differently in BSP kernels and don't necessarily need explicit includes like <dt-bindings/input/input.h> that would be required in mainline kernel device trees.
Learnt from: rpardini
Repo: armbian/build PR: 8820
File: config/sources/families/include/meson64_common.inc:51-53
Timestamp: 2025-10-26T12:56:29.185Z
Learning: In the Armbian build framework, scripts/config correctly handles kernel configuration option names both with and without the CONFIG_ prefix, so opts_m+=("CONFIG_RTL8822CS") and opts_m+=("RTL8822CS") are both valid and will work correctly.
| CONFIG_SYS_WHITE_ON_BLACK=y | ||
|
|
||
| # | ||
| # TrueType Fonts |
Collaborator
There was a problem hiding this comment.
Is this comment just copypasta?
Author
There was a problem hiding this comment.
I'm currently testing how to drive HDMI under U-Boot.
| CONFIG_MTD_DEVICE=y | ||
| CONFIG_NAND=y | ||
| CONFIG_MTD_SPI_NAND=y | ||
| CONFIG_SPI_FLASH=y |
Collaborator
There was a problem hiding this comment.
Does this board have SPI flash?
https://shimetadevice.com/wp-content/uploads/2025/06/Motherboard-AIoT-3588A-V1.0-Specifications-V1.pdf does not mention it.
Author
There was a problem hiding this comment.
This is a copy; I haven't deleted it yet.
| @@ -0,0 +1,12 @@ | |||
| #Rockchip RK3588 SoC octa core 4-16GB SoC 2.5GBe PoE eMMC USB3 NvME | |||
| BOARD_NAME="Aiot rk3588" | |||
Collaborator
There was a problem hiding this comment.
Should Shimeta be explicitly mentioned here? Aiot feels a hair generic.
@coderabbitai
Contributor
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Check BOARD_NAME patterns in existing board configuration files
echo "=== BOARD_NAME patterns in board configs ==="
rg -n 'BOARD_NAME=' config/boards/ -A 0 | head -50
echo -e "\n=== Rockchip RK3588 board names specifically ==="
rg -n 'BOARD_NAME=' config/boards/*rk3588*.conf -A 0
echo -e "\n=== Board configs with 'aiot' or 'Aiot' in filename or BOARD_NAME ==="
fd -e conf -e csc aiot config/boards/
rg -i 'aiot' config/boards/ -n -C 1
Length of output: 3575
@tabrisnet, you're absolutely right! Looking at the naming patterns across Armbian board configurations, manufacturer/vendor names are typically included in BOARD_NAME for clear identification. Examples include:
- "Xiaomi Elish"
- "YouYeeToo YY3568"
- "Turing RK1"
- "ThinkPad X13s"
- "Tinker Board"
"Aiot" (AI + IoT) is indeed quite generic and doesn't uniquely identify this board. Since the filename already includes shimeta, the BOARD_NAME should follow the same pattern. I'd recommend:
BOARD_NAME="Shimeta Aiot RK3588"This would be consistent with how other vendors name their boards in the Armbian build system and makes it clear which manufacturer's board this is.
🧠 Learnings used
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 (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: igorpecovnik
Repo: armbian/build PR: 8789
File: config/kernel/linux-sunxi64-edge.config:839-839
Timestamp: 2025-10-22T07:51:53.015Z
Learning: In Armbian's wireless driver configuration, CONFIG_RK_WIFI_DEVICE_* options are Rockchip-specific device registration settings, while CONFIG_WLAN_UWE* are the actual cross-platform driver modules for UWE5622 wireless chips. The UWE5622 chip (manufactured by Unisoc/Spreadtrum) is used on multiple Allwinner boards including Orange Pi Zero 2/2W/3 and Orange Pi 3 LTS, so CONFIG_WLAN_UWE5621/5622 along with Unisoc infrastructure options (CONFIG_SPARD_WLAN_SUPPORT, CONFIG_SC23XX, CONFIG_UNISOC_WIFI_PS, CONFIG_WCN_BSP_DRIVER_BUILDIN) are correct in sunxi64 kernel configs.
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: 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: amazingfate
Repo: armbian/build PR: 8619
File: config/sources/families/rockchip.conf:64-70
Timestamp: 2025-09-14T06:29:18.958Z
Learning: In the Armbian build system, vendor branch configurations in family files are designed to be shared across multiple SoCs within the same family that use the same vendor kernel tree. For example, rk35xx and rockchip-rk3588 families both use identical vendor branch settings (same KERNELSOURCE, KERNELBRANCH, and KERNELPATCHDIR), demonstrating that vendor branches are intentionally generic rather than SoC-specific.
Learnt from: pyavitz
Repo: armbian/build PR: 8388
File: config/boards/kickpik2b.conf:1-14
Timestamp: 2025-07-17T04:12:33.125Z
Learning: In the Armbian build system, board configuration files (*.conf) follow a project standard of not including shebang lines, even though they contain bash code and are sourced by the build system. This is an established Armbian convention that individual contributors are expected to follow, and changes to this standard would require broader project maintainer approval.
Learnt from: EvilOlaf
Repo: armbian/build PR: 8619
File: config/sources/families/rockchip.conf:64-70
Timestamp: 2025-09-14T06:10:25.610Z
Learning: In the Armbian build system, rk32xx and rk33xx Rockchip SoCs no longer have BSP-based (vendor) kernel branches. The rk3506 is the first 32-bit Rockchip SoC to use the vendor branch in the current codebase.
Learnt from: EvilOlaf
Repo: armbian/build PR: 8586
File: config/boards/nanopi-r76s.conf:15-21
Timestamp: 2025-09-07T17:39:32.272Z
Learning: In the Armbian build system, the variables $BOARD and $SDCARD are always set by the build framework, so guard checks for these variables are unnecessary in board configuration files and hook functions.
Learnt from: amazingfate
Repo: armbian/build PR: 8619
File: config/sources/families/rockchip.conf:222-230
Timestamp: 2025-09-14T06:32:29.806Z
Learning: In the Armbian build system, the write_uboot_platform() function implementations follow different patterns across Rockchip family files. The newer standard (used in rockchip64_common.inc and rk3506) includes 'status=none' parameter in dd commands, while older implementations (rk3288, rk322x) use an older pattern without this parameter. The rk3506 implementation correctly follows the current Rockchip family standard.
| @@ -0,0 +1,12 @@ | |||
| #Rockchip RK3588 SoC octa core 4-16GB SoC 2.5GBe PoE eMMC USB3 NvME | |||
Collaborator
There was a problem hiding this comment.
What PoE? It's not mentioned in https://shimetadevice.com/wp-content/uploads/2025/06/Motherboard-AIoT-3588A-V1.0-Specifications-V1.pdf
ditto NVMe.
Author
There was a problem hiding this comment.
This is a file I copied and modified from another configuration file; it hasn't been modified yet.
tabrisnet
added
02
Author
|
I'd like to add some information. Currently, there are three versions of this series of boards: v1.1, v1.2, and v1.3. I currently have version v1.3. |
Collaborator
the good/bad news: No idea where/how to find the previous revisions. |
Author
So far, I've only seen V1.2 and V1.1 on China's Xianyu platform. |
Author
|
https://b23.tv/BV1N3U4B6Efw HDMI work |
|
@coderabbitai review The development board does in fact have a reserved NVMe interface, which is currently covered by the mini‑PCIe connector. My understanding is that by removing the mini‑PCIe and soldering the NVMe interface, the slot could be enabled and used. |
Contributor
🧩 Analysis chain🏁 Script executed: Length of output: 9128 🏁 Script executed: Length of output: 2587 🏁 Script executed: Length of output: 372 🏁 Script executed: Length of output: 587 @ZZZ8, thank you for the hardware clarification! I've reviewed the PR with this NVMe capability in mind. Review FindingsThe board configuration already documents the PCIe/M.2 flexibility in the comment (line 2 of
However, the NVMe driver support is missing from the U-Boot defconfig. RecommendationI recommend adding NVMe driver support to Suggested addition (around line 147, after the This would be inserted after the Benefits:
The minimal device tree currently in the PR is appropriate for U-Boot. The full PCIe node configuration would typically be in the kernel device tree for runtime support. Would you like me to prepare the specific configuration addition, or would @ghhccghk prefer to add this enhancement? 🧠 Learnings used✅ Actions performedReview triggered.
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (2)
config/boards/shimeta-aiot-rk3588a.conf (1)
3-3: Make BOARD_NAME explicitly include the vendor for disambiguation
BOARD_NAME="Aiot rk3588"is still quite generic; previous review already noted that “Aiot” alone doesn’t uniquely identify this board among AIoT‑style designs. To align with other Armbian boards and the filename, something like:BOARD_NAME="Shimeta Aiot RK3588A"would be clearer and easier to recognize in menus and logs.
patch/u-boot/legacy/u-boot-radxa-rk35xx/defconfig/aiot_rk3588a_defconfig (1)
141-152: PCIe is enabled but SATA support is missing despite board comment mentioning SATAYou have PCIe support (
CONFIG_PCI,CONFIG_DM_PCI,CONFIG_PCIE_DW_ROCKCHIP,CONFIG_PHY_ROCKCHIP_SNPS_PCIE3), but there’s no SATA / AHCI / SCSI stack enabled in this defconfig. Given the board description inshimeta-aiot-rk3588a.confnow explicitly lists SATA, it’s likely users will expect SATA disks to be visible in U‑Boot.Enabling the standard SATA stack (assuming the RK3588 wiring matches the usual AHCI‑over‑PCIe pattern) would look roughly like:
+CONFIG_SATA=y +CONFIG_SCSI=y +CONFIG_DM_SCSI=y +CONFIG_SCSI_AHCI=y +CONFIG_AHCI_PCI=y +CONFIG_CMD_SATA=yYou can mirror the exact set from another RK3588 board in this tree that already has working SATA.
🧹 Nitpick comments (3)
config/boards/shimeta-aiot-rk3588a.conf (1)
1-2: Trim/normalize the header comments to match board‑config conventionsCurrent header is two long comment lines listing many features and variants. The typical pattern is a single, concise one‑line description of SoC, RAM range, and key interfaces.
Consider collapsing into one shorter line and double‑checking that all features you list (e.g. SATA, CAN, HDMI‑in, LVDS/EDP variants) are actually present or at least available across the known board revisions, so the comment doesn’t over‑promise capabilities.
patch/u-boot/legacy/u-boot-radxa-rk35xx/defconfig/aiot_rk3588a_defconfig (2)
121-140: SPI flash and NAND support: keep only if the board actually has themThis defconfig enables both NAND and SPI‑NOR (
CONFIG_NAND,CONFIG_MTD_SPI_NAND,CONFIG_SPI_FLASH*,CONFIG_ROCKCHIP_SPI,CONFIG_ROCKCHIP_SFC). Earlier discussion suggested these were copied from another board and might not match the real hardware.If the Aiot‑rk3588a has no on‑board SPI flash or NAND, you could drop these to simplify the config; if it does, leaving them enabled is fine. Worth double‑checking against the actual PCB/datasheet.
194-233: Clean up conflicting / duplicate DRM and display optionsThis block defines video/DRM options twice and sets
CONFIG_DRM_ROCKCHIP_ANALOGIX_DPboth toy(Line 198) and later to “is not set” (Line 228). Kconfig will honor the last value (disabled), but the contradiction makes the defconfig harder to read and maintain.If ANALOGIX DP is not actually wired on this board, consider dropping the earlier
CONFIG_DRM_ROCKCHIP_ANALOGIX_DP=yline and, optionally, runningmake savedefconfigagainst this U‑Boot tree to normalize duplicates (CONFIG_DM_VIDEO,CONFIG_DISPLAY,CONFIG_DRM_ROCKCHIP, etc.).
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Disabled knowledge base sources:
- Jira integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (3)
config/boards/shimeta-aiot-rk3588a.conf(1 hunks)patch/u-boot/legacy/u-boot-radxa-rk35xx/defconfig/aiot_rk3588a_defconfig(1 hunks)patch/u-boot/legacy/u-boot-radxa-rk35xx/dt/rk3588-aiot-rk3588a.dts(1 hunks)
🧰 Additional context used
🧠 Learnings (26)
📓 Common learnings
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: 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 (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: amazingfate
Repo: armbian/build PR: 8619
File: config/sources/families/rockchip.conf:222-230
Timestamp: 2025-09-14T06:32:29.806Z
Learning: In the Armbian build system, the write_uboot_platform() function implementations follow different patterns across Rockchip family files. The newer standard (used in rockchip64_common.inc and rk3506) includes 'status=none' parameter in dd commands, while older implementations (rk3288, rk322x) use an older pattern without this parameter. The rk3506 implementation correctly follows the current Rockchip family standard.
Learnt from: Grippy98
Repo: armbian/build PR: 8624
File: config/boards/sk-am62p.conf:8-8
Timestamp: 2025-09-12T21:44:09.061Z
Learning: For TI K3 family boards in Armbian, BOOT_FDT_FILE uses .dts extension (not .dtb) as the standard convention. The build system handles this correctly by automatically compiling .dts to .dtb during kernel build and using the BOOT_FDT_FILE value directly in bootloader configurations.
Learnt from: igorpecovnik
Repo: armbian/build PR: 8789
File: config/kernel/linux-sunxi64-edge.config:839-839
Timestamp: 2025-10-22T07:51:53.015Z
Learning: In Armbian's wireless driver configuration, CONFIG_RK_WIFI_DEVICE_* options are Rockchip-specific device registration settings, while CONFIG_WLAN_UWE* are the actual cross-platform driver modules for UWE5622 wireless chips. The UWE5622 chip (manufactured by Unisoc/Spreadtrum) is used on multiple Allwinner boards including Orange Pi Zero 2/2W/3 and Orange Pi 3 LTS, so CONFIG_WLAN_UWE5621/5622 along with Unisoc infrastructure options (CONFIG_SPARD_WLAN_SUPPORT, CONFIG_SC23XX, CONFIG_UNISOC_WIFI_PS, CONFIG_WCN_BSP_DRIVER_BUILDIN) are correct in sunxi64 kernel configs.
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: amazingfate
Repo: armbian/build PR: 8619
File: config/sources/families/rockchip.conf:64-70
Timestamp: 2025-09-14T06:29:18.958Z
Learning: In the Armbian build system, vendor branch configurations in family files are designed to be shared across multiple SoCs within the same family that use the same vendor kernel tree. For example, rk35xx and rockchip-rk3588 families both use identical vendor branch settings (same KERNELSOURCE, KERNELBRANCH, and KERNELPATCHDIR), demonstrating that vendor branches are intentionally generic rather than SoC-specific.
Learnt from: EvilOlaf
Repo: armbian/build PR: 8619
File: config/sources/families/rockchip.conf:64-70
Timestamp: 2025-09-14T06:10:25.610Z
Learning: In the Armbian build system, rk32xx and rk33xx Rockchip SoCs no longer have BSP-based (vendor) kernel branches. The rk3506 is the first 32-bit Rockchip SoC to use the vendor branch in the current codebase.
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: EvilOlaf
Repo: armbian/build PR: 8886
File: patch/kernel/rk35xx-vendor-6.1/dt/rk3528-nanopi-rev01.dts:9-9
Timestamp: 2025-11-08T06:39:24.527Z
Learning: In Armbian's Rockchip vendor kernel branches (rk35xx-vendor), device tree files may not require the same headers as mainline Linux. For example, input key definitions like KEY_BACK and KEY_VOLUMEUP may be handled differently in BSP kernels and don't necessarily need explicit includes like <dt-bindings/input/input.h> that would be required in mainline kernel device trees.
📚 Learning: 2025-11-08T06:39:24.527Z
Learnt from: EvilOlaf
Repo: armbian/build PR: 8886
File: patch/kernel/rk35xx-vendor-6.1/dt/rk3528-nanopi-rev01.dts:9-9
Timestamp: 2025-11-08T06:39:24.527Z
Learning: In Armbian's Rockchip vendor kernel branches (rk35xx-vendor), device tree files may not require the same headers as mainline Linux. For example, input key definitions like KEY_BACK and KEY_VOLUMEUP may be handled differently in BSP kernels and don't necessarily need explicit includes like <dt-bindings/input/input.h> that would be required in mainline kernel device trees.
Applied to files:
patch/u-boot/legacy/u-boot-radxa-rk35xx/dt/rk3588-aiot-rk3588a.dtsconfig/boards/shimeta-aiot-rk3588a.confpatch/u-boot/legacy/u-boot-radxa-rk35xx/defconfig/aiot_rk3588a_defconfig
📚 Learning: 2025-11-15T14:33:30.654Z
Learnt from: SuperKali
Repo: armbian/build PR: 8936
File: patch/kernel/archive/rockchip64-6.18/dt/rk3576-nanopi-r76s.dts:800-802
Timestamp: 2025-11-15T14:33:30.654Z
Learning: In RK3576 device tree files (like rk3576-nanopi-r76s.dts), the serial0 alias is already defined in the upstream kernel's rk3576.dtsi base file, so board-specific DTS files do not need to redeclare it when enabling &uart0 for serial console.
Applied to files:
patch/u-boot/legacy/u-boot-radxa-rk35xx/dt/rk3588-aiot-rk3588a.dts
📚 Learning: 2025-11-02T20:49:56.719Z
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.
Applied to files:
config/boards/shimeta-aiot-rk3588a.confpatch/u-boot/legacy/u-boot-radxa-rk35xx/defconfig/aiot_rk3588a_defconfig
📚 Learning: 2025-09-18T03:36:17.862Z
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).
Applied to files:
config/boards/shimeta-aiot-rk3588a.confpatch/u-boot/legacy/u-boot-radxa-rk35xx/defconfig/aiot_rk3588a_defconfig
📚 Learning: 2025-10-26T10:41:35.118Z
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.
Applied to files:
config/boards/shimeta-aiot-rk3588a.confpatch/u-boot/legacy/u-boot-radxa-rk35xx/defconfig/aiot_rk3588a_defconfig
📚 Learning: 2025-07-17T04:12:33.125Z
Learnt from: pyavitz
Repo: armbian/build PR: 8388
File: config/boards/kickpik2b.conf:1-14
Timestamp: 2025-07-17T04:12:33.125Z
Learning: In the Armbian build system, board configuration files (*.conf) follow a project standard of not including shebang lines, even though they contain bash code and are sourced by the build system. This is an established Armbian convention that individual contributors are expected to follow, and changes to this standard would require broader project maintainer approval.
Applied to files:
config/boards/shimeta-aiot-rk3588a.confpatch/u-boot/legacy/u-boot-radxa-rk35xx/defconfig/aiot_rk3588a_defconfig
📚 Learning: 2025-09-18T03:36:17.862Z
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/
Applied to files:
config/boards/shimeta-aiot-rk3588a.confpatch/u-boot/legacy/u-boot-radxa-rk35xx/defconfig/aiot_rk3588a_defconfig
📚 Learning: 2025-09-14T06:32:29.806Z
Learnt from: amazingfate
Repo: armbian/build PR: 8619
File: config/sources/families/rockchip.conf:222-230
Timestamp: 2025-09-14T06:32:29.806Z
Learning: In the Armbian build system, the write_uboot_platform() function implementations follow different patterns across Rockchip family files. The newer standard (used in rockchip64_common.inc and rk3506) includes 'status=none' parameter in dd commands, while older implementations (rk3288, rk322x) use an older pattern without this parameter. The rk3506 implementation correctly follows the current Rockchip family standard.
Applied to files:
config/boards/shimeta-aiot-rk3588a.confpatch/u-boot/legacy/u-boot-radxa-rk35xx/defconfig/aiot_rk3588a_defconfig
📚 Learning: 2025-11-10T22:05:40.490Z
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.
Applied to files:
config/boards/shimeta-aiot-rk3588a.conf
📚 Learning: 2025-09-14T06:29:18.958Z
Learnt from: amazingfate
Repo: armbian/build PR: 8619
File: config/sources/families/rockchip.conf:64-70
Timestamp: 2025-09-14T06:29:18.958Z
Learning: In the Armbian build system, vendor branch configurations in family files are designed to be shared across multiple SoCs within the same family that use the same vendor kernel tree. For example, rk35xx and rockchip-rk3588 families both use identical vendor branch settings (same KERNELSOURCE, KERNELBRANCH, and KERNELPATCHDIR), demonstrating that vendor branches are intentionally generic rather than SoC-specific.
Applied to files:
config/boards/shimeta-aiot-rk3588a.confpatch/u-boot/legacy/u-boot-radxa-rk35xx/defconfig/aiot_rk3588a_defconfig
📚 Learning: 2025-09-07T17:39:32.272Z
Learnt from: EvilOlaf
Repo: armbian/build PR: 8586
File: config/boards/nanopi-r76s.conf:15-21
Timestamp: 2025-09-07T17:39:32.272Z
Learning: In the Armbian build system, the variables $BOARD and $SDCARD are always set by the build framework, so guard checks for these variables are unnecessary in board configuration files and hook functions.
Applied to files:
config/boards/shimeta-aiot-rk3588a.conf
📚 Learning: 2025-10-14T05:08:11.785Z
Learnt from: EvilOlaf
Repo: armbian/build PR: 8754
File: config/boards/bestv-r3300-l.csc:14-16
Timestamp: 2025-10-14T05:08:11.785Z
Learning: In the Armbian build system, BOOTBRANCH_BOARD is a valid framework variable used as a fallback when BOOTBRANCH is unset. The framework checks BOOTBRANCH_BOARD before applying the default bootloader branch value (see config/sources/common.conf). Board configuration files can use BOOTBRANCH_BOARD to specify the bootloader branch.
Applied to files:
config/boards/shimeta-aiot-rk3588a.conf
📚 Learning: 2025-09-14T06:10:25.610Z
Learnt from: EvilOlaf
Repo: armbian/build PR: 8619
File: config/sources/families/rockchip.conf:64-70
Timestamp: 2025-09-14T06:10:25.610Z
Learning: In the Armbian build system, rk32xx and rk33xx Rockchip SoCs no longer have BSP-based (vendor) kernel branches. The rk3506 is the first 32-bit Rockchip SoC to use the vendor branch in the current codebase.
Applied to files:
config/boards/shimeta-aiot-rk3588a.conf
📚 Learning: 2025-11-10T23:44:53.363Z
Learnt from: tabrisnet
Repo: armbian/build PR: 0
File: :0-0
Timestamp: 2025-11-10T23:44:53.363Z
Learning: For the RV1106 family in Armbian (config/sources/families/rockchip-rv1106.conf), udev.children-max=1 is set in the kernel boot parameters to prevent early-boot OOM errors. The RV1106 has a single-core CPU, so parallelism in udev child processes provides no practical benefit. Testing higher values is impractical due to the difficulty of monitoring at this early boot stage.
Applied to files:
config/boards/shimeta-aiot-rk3588a.confpatch/u-boot/legacy/u-boot-radxa-rk35xx/defconfig/aiot_rk3588a_defconfig
📚 Learning: 2025-07-25T03:51:50.830Z
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.
Applied to files:
patch/u-boot/legacy/u-boot-radxa-rk35xx/defconfig/aiot_rk3588a_defconfig
📚 Learning: 2025-08-30T04:13:16.457Z
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.
Applied to files:
patch/u-boot/legacy/u-boot-radxa-rk35xx/defconfig/aiot_rk3588a_defconfig
📚 Learning: 2025-11-20T18:20:11.985Z
Learnt from: EvilOlaf
Repo: armbian/build PR: 8968
File: patch/u-boot/u-boot-sunxi/arm64-dts-sun50i-h6-orangepi.dtsi-Rollback-r_rsb-to-r_i2c.patch:36-36
Timestamp: 2025-11-20T18:20:11.985Z
Learning: The rewrite-patches tool (REWRITE_PATCHES=yes) in the Armbian build system can inadvertently introduce semantic changes when the u-boot/kernel git base revision differs from expected state. The tool applies patches, commits them, and re-exports them using git format-patch, which can cause the re-exported patch to reflect the base revision's state rather than preserving the original patch intent. This is particularly problematic for device tree changes like interrupt specifications. The tool currently lacks validation mechanisms to detect such semantic drift, and affected patches must be manually corrected after rewriting.
Applied to files:
patch/u-boot/legacy/u-boot-radxa-rk35xx/defconfig/aiot_rk3588a_defconfig
📚 Learning: 2025-07-25T03:51:50.830Z
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.
Applied to files:
patch/u-boot/legacy/u-boot-radxa-rk35xx/defconfig/aiot_rk3588a_defconfig
📚 Learning: 2025-10-22T07:51:53.015Z
Learnt from: igorpecovnik
Repo: armbian/build PR: 8789
File: config/kernel/linux-sunxi64-edge.config:839-839
Timestamp: 2025-10-22T07:51:53.015Z
Learning: In Armbian's wireless driver configuration, CONFIG_RK_WIFI_DEVICE_* options are Rockchip-specific device registration settings, while CONFIG_WLAN_UWE* are the actual cross-platform driver modules for UWE5622 wireless chips. The UWE5622 chip (manufactured by Unisoc/Spreadtrum) is used on multiple Allwinner boards including Orange Pi Zero 2/2W/3 and Orange Pi 3 LTS, so CONFIG_WLAN_UWE5621/5622 along with Unisoc infrastructure options (CONFIG_SPARD_WLAN_SUPPORT, CONFIG_SC23XX, CONFIG_UNISOC_WIFI_PS, CONFIG_WCN_BSP_DRIVER_BUILDIN) are correct in sunxi64 kernel configs.
Applied to files:
patch/u-boot/legacy/u-boot-radxa-rk35xx/defconfig/aiot_rk3588a_defconfig
📚 Learning: 2025-03-31T22:20:41.849Z
Learnt from: rpardini
Repo: armbian/build PR: 8044
File: patch/u-boot/v2025.04/cmd-fileenv-read-string-from-file-into-env.patch:73-75
Timestamp: 2025-03-31T22:20:41.849Z
Learning: When porting patches between U-Boot versions (like from 2025.01 to 2025.04), rpardini prefers to maintain patches as-is rather than introducing refactoring changes, even when potential improvements are identified. This approach prioritizes consistency and reduces the risk of introducing new issues.
Applied to files:
patch/u-boot/legacy/u-boot-radxa-rk35xx/defconfig/aiot_rk3588a_defconfig
📚 Learning: 2025-09-14T05:23:42.991Z
Learnt from: EvilOlaf
Repo: armbian/build PR: 8632
File: config/sources/families/include/rockchip64_common.inc:327-334
Timestamp: 2025-09-14T05:23:42.991Z
Learning: In the Armbian build system for Rockchip boards, SPI flash consistently maps to /dev/mtd0, so hard-coding this device path in flashcp commands is acceptable and based on hardware conventions rather than being a bug.
Applied to files:
patch/u-boot/legacy/u-boot-radxa-rk35xx/defconfig/aiot_rk3588a_defconfig
📚 Learning: 2025-10-26T12:56:29.185Z
Learnt from: rpardini
Repo: armbian/build PR: 8820
File: config/sources/families/include/meson64_common.inc:51-53
Timestamp: 2025-10-26T12:56:29.185Z
Learning: In the Armbian build framework, scripts/config correctly handles kernel configuration option names both with and without the CONFIG_ prefix, so opts_m+=("CONFIG_RTL8822CS") and opts_m+=("RTL8822CS") are both valid and will work correctly.
Applied to files:
patch/u-boot/legacy/u-boot-radxa-rk35xx/defconfig/aiot_rk3588a_defconfig
📚 Learning: 2025-07-27T15:53:30.629Z
Learnt from: pyavitz
Repo: armbian/build PR: 8421
File: config/kernel/linux-sunxi64-edge.config:805-825
Timestamp: 2025-07-27T15:53:30.629Z
Learning: In the Armbian build system, kernel configurations prioritize broad hardware compatibility over optimization concerns. Even when including numerous legacy/obsolete drivers causes technical issues like increased initramfs size and slower enumeration, the project philosophy is to "appease the masses" by ensuring maximum device compatibility rather than optimizing for specific use cases.
Applied to files:
patch/u-boot/legacy/u-boot-radxa-rk35xx/defconfig/aiot_rk3588a_defconfig
📚 Learning: 2025-08-30T06:56:33.372Z
Learnt from: tabrisnet
Repo: armbian/build PR: 0
File: :0-0
Timestamp: 2025-08-30T06:56:33.372Z
Learning: In Armbian kernel configuration, the BTRFS configuration logic preserves existing settings (whether built-in 'y' or module 'm') and only sets BTRFS_FS to module when it was previously disabled or not set, achieving "allow but not require" flexibility while maintaining backward compatibility.
Applied to files:
patch/u-boot/legacy/u-boot-radxa-rk35xx/defconfig/aiot_rk3588a_defconfig
📚 Learning: 2025-10-22T07:56:19.424Z
Learnt from: igorpecovnik
Repo: armbian/build PR: 8789
File: config/kernel/linux-sunxi64-edge.config:839-839
Timestamp: 2025-10-22T07:56:19.424Z
Learning: In Linux kernel configuration, some `=y` (builtin) options are infrastructure or feature flags that enable subsystems or features for modular drivers, rather than directly compiling code into the kernel. For example, in Armbian wireless configs, options like CONFIG_SPARD_WLAN_SUPPORT=y, CONFIG_SC23XX=y, CONFIG_WCN_BSP_DRIVER_BUILDIN=y, CONFIG_UNISOC_WIFI_PS=y are module infrastructure/feature enablers, while the actual drivers (CONFIG_WLAN_UWE5621=m, CONFIG_WLAN_UWE5622=m) remain as loadable modules. These infrastructure options don't cause kernel bloat.
Applied to files:
patch/u-boot/legacy/u-boot-radxa-rk35xx/defconfig/aiot_rk3588a_defconfig
🔇 Additional comments (4)
patch/u-boot/legacy/u-boot-radxa-rk35xx/dt/rk3588-aiot-rk3588a.dts (1)
1-15: DTS header, includes, and top-level identification look consistentSPDX header, rk3588 base includes, and
model/compatiblevalues align with the board and BOOT_FDT_FILE naming. No issues from a U‑Boot DTS perspective.config/boards/shimeta-aiot-rk3588a.conf (1)
4-13: Core board parameters look consistent with RK3588 vendor setup
BOARDFAMILY="rockchip-rk3588", vendor kernel targets, BOOTCONFIG, BOOT_SOC, and BOOT_FDT_FILE all line up with the new U‑Boot defconfig and DTS naming. No functional issues spotted here.patch/u-boot/legacy/u-boot-radxa-rk35xx/defconfig/aiot_rk3588a_defconfig (2)
90-123: ADC and key input configuration matches the DTS usage
CONFIG_SARADC_ROCKCHIP_V2=y,CONFIG_DM_KEY=y, andCONFIG_ADC_KEY=yare enabled here and line up with theadc-keysblock you added in the board DTS. That’s the right combination for the analog volume key to be usable in U‑Boot.
20-27: TARGET_EVB_RK3588 with a board‑specific DEFAULT_DEVICE_TREE looks acceptableUsing the generic
CONFIG_TARGET_EVB_RK3588=ytogether withCONFIG_DEFAULT_DEVICE_TREE="rk3588-aiot-rk3588a"matches how other RK3588 boards in vendor trees are typically structured (common target, board‑specific DT). No change needed as long as this aligns with the existing Radxa RK3588 defconfigs in this directory.
Comment on lines
+16
to
+30
| adc-keys { | ||
| compatible = "adc-keys"; | ||
| io-channels = <&saradc 1>; | ||
| io-channel-names = "buttons"; | ||
| keyup-threshold-microvolt = <1800000>; | ||
| u-boot,dm-pre-reloc; | ||
| status = "okay"; | ||
|
|
||
| volumeup-key { | ||
| u-boot,dm-pre-reloc; | ||
| linux,code = <KEY_VOLUMEUP>; | ||
| label = "volume up"; | ||
| press-threshold-microvolt = <1750>; | ||
| }; | ||
| }; |
Contributor
There was a problem hiding this comment.
🧩 Analysis chain
Fix press-threshold-microvolt units for volumeup-key
keyup-threshold-microvolt = <1800000>; is in microvolts (1.8 V), but press-threshold-microvolt = <1750>; is 1.75 mV, which is three orders of magnitude lower and effectively never reached in this context. This is almost certainly a unit/zero‑omission bug.
If you intended ~1.75 V, adjust to microvolts, e.g.:
- press-threshold-microvolt = <1750>;
+ press-threshold-microvolt = <1750000>;Please recheck against your ADC divider/expected key voltage and tweak the exact value if needed.
I'll verify the ADC keys unit specification and device tree binding documentation to confirm whether this is indeed a unit mismatch issue.
🌐 Web query:
Linux adc-keys device tree binding press-threshold-microvolt units
💡 Result:
The press-threshold-microvolt property is specified in microvolts (µV) as an integer. e.g. press-threshold-microvolt = <500000>; means 500,000 µV = 0.5 V. [1][2]
Sources:
- adc-keys device-tree binding (Documentation/devicetree/bindings/input/adc-keys.yaml). [1]
- adc-keys documentation excerpt (Documentation/devicetree/bindings/input/adc-keys.txt). [2]
🌐 Web query:
ADC keys device tree RK3588 threshold units microvolts
💡 Result:
Yes — the adc-keys device-tree binding uses microvolts. The binding properties are named press-threshold-microvolt and keyup-threshold-microvolt and their values are specified in microvolts (e.g. 2000000, 1800000) — see the adc-keys binding docs and RK3588 DTS examples. [1][2]
Sources:
- adc-keys device-tree binding (press-/keyup-threshold-microvolt = microvolts). [1]
- RK3588 board DT examples using press-threshold-microvolt / keyup-threshold-microvolt (values in microvolts). [2]
🌐 Web query:
device tree adc-keys keyup-threshold press-threshold specifications
💡 Result:
Summary of adc-keys Device Tree properties (keyup / press thresholds)
-
Purpose
- adc-keys models resistor‑ladder (ADC) buttons. The driver compares ADC voltages against configured thresholds to decide key press/release. [1]
-
Top-level key release threshold
- keyup-threshold-mv (or keyup-threshold-microvolt in some DTS examples) — voltage below which all keys are considered UP (i.e. release cutoff). This property is required. Units: millivolts in the binding docs; some real DTSes and patches use microvolt variants (e.g. keyup-threshold-microvolt). [1][3]
-
Per-key press thresholds
- press-thresholds-mv (or press-threshold-microvolt) — array of voltages that indicate the key is considered PRESSED. For buttons that can form combinations, list one value per combination (the driver does not compute combinations itself; you supply each expected voltage). This property is required for each child key node. [1]
-
Other relevant properties
- sample-period-ms / poll-interval — sampling/poll period in ms (binding default 20 ms unless overridden). [1][4]
- io-channels / io-channel-names — ADC channel phandle(s). [1]
- linux,code / zephyr,code — key code to emit; linux,input-type may be allowed (patches discussed). [3]
-
Notes / examples
- Example (from binding): keyup-threshold-mv = <0>; child: press-thresholds-mv = <1650>, <2536>; where each value is in mV. Many device trees in the wild use microvolt properties (e.g. press-threshold-microvolt = <1800000>); check kernel/tree/board binding version used by your kernel/tooling and match units. [1][2][4]
Sources
- Device-tree binding documentation for "adc-keys". [1]
- Example kernel DTS patches and dts usages showing *_microvolt properties and poll-interval. [2][3][4]
References
[1] adc-keys devicetree binding (binding doc / examples).
[2] adc-keys binding (Bridle/Zephyr page) (example).
[3] Kernel DTS patches / examples showing keyup-threshold-microvolt.
[4] Rockchip / NanoPi DTS examples using press-threshold-microvolt and poll-interval.
Fix press-threshold-microvolt units for volumeup-key
The press-threshold-microvolt property is specified in microvolts (µV), consistent with keyup-threshold-microvolt = <1800000>; (1.8 V). The current value <1750> represents only 1.75 mV—approximately three orders of magnitude lower than the keyup threshold—and will never trigger in practice.
Correct to:
- press-threshold-microvolt = <1750>;
+ press-threshold-microvolt = <1750000>;This assumes ~1.75 V is the intended press threshold; verify against your ADC divider and adjust the exact value as needed.
📝 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.
Suggested change
| adc-keys { | |
| compatible = "adc-keys"; | |
| io-channels = <&saradc 1>; | |
| io-channel-names = "buttons"; | |
| keyup-threshold-microvolt = <1800000>; | |
| u-boot,dm-pre-reloc; | |
| status = "okay"; | |
| volumeup-key { | |
| u-boot,dm-pre-reloc; | |
| linux,code = <KEY_VOLUMEUP>; | |
| label = "volume up"; | |
| press-threshold-microvolt = <1750>; | |
| }; | |
| }; | |
| adc-keys { | |
| compatible = "adc-keys"; | |
| io-channels = <&saradc 1>; | |
| io-channel-names = "buttons"; | |
| keyup-threshold-microvolt = <1800000>; | |
| u-boot,dm-pre-reloc; | |
| status = "okay"; | |
| volumeup-key { | |
| u-boot,dm-pre-reloc; | |
| linux,code = <KEY_VOLUMEUP>; | |
| label = "volume up"; | |
| press-threshold-microvolt = <1750000>; | |
| }; | |
| }; |
🤖 Prompt for AI Agents
In patch/u-boot/legacy/u-boot-radxa-rk35xx/dt/rk3588-aiot-rk3588a.dts around
lines 16 to 30, the volumeup-key's press-threshold-microvolt is mistakenly set
to 1750 (µV) instead of a value in microvolts; update press-threshold-microvolt
to the correct microvolt value for ~1.75 V (e.g. 1750000) so it matches the unit
used by keyup-threshold-microvolt and verify against the ADC divider to adjust
the exact value as needed.
ZZZ8
approved these changes
Nov 24, 2025
ZZZ8
approved these changes
Nov 25, 2025
"After searching and comparing product images from multiple sellers, I found that most of the development boards currently listed on Xianyu (a major second-hand marketplace in China) are version 1.3." "After comparing the photos in the manual with the v1.3 board, the component layout appears unchanged." |
Author
The main concern is that modifications to different versions of the network may cause compatibility issues. |
Collaborator
|
Perhaps a note should be made in the board config file with appropriate document links [use archive.org if we don't trust the vendor to not change files].
Take any references also from any official BSPs, not that I've seen much on their website. Are different DTBs provided in the Android builds?
|
Author
The official Android system does indeed include other versions of DTS. |
Author
|
|
Author
iperf3 test for ethernet
|
ghhccghk
force-pushed
the
pr
branch
2 times, most recently
from
06bff69 to
b046e01
Compare
ZZZ8
approved these changes
Nov 30, 2025
Author
|
This development board currently has a built-in MCU, so we need to reverse engineer the protocol. |
…e. Enable EDP 0 and keep EDP 1 disabled.
…ut down will cause the kernel to crash.
…PIO, and add USB Type-C and regulator configurations
…le and configure ADC keys
Author
This is the official Android system boot log. |
Author
|
NCA 9555 is work operational. |
ZZZ8
approved these changes
Dec 4, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Adds support for the Aiot-rk3588a (Shimeta) board.
This change implements support for the Aiot-rk3588a board, including:
aiot_rk3588a_defconfiguboot configuration fileFeature/Change Documentation Summary
Test Process
Checklist:
Summary by CodeRabbit
✏️ Tip: You can customize this high-level summary in your review settings.