This PR adds official Armbian support for two EasePi IoT gateway/NAS devices#9880
This PR adds official Armbian support for two EasePi IoT gateway/NAS devices#9880ifroncy01 wants to merge 14 commits into
Conversation
Add easepi-a2-rk3568_defconfig Add easepi-r2-rk3588_defconfig
Add rk3568-easepi-a2-u-boot.dtsi Add rk3588-easepi-r2-u-boot.dtsi
Add rk3568-easepi-a2.dts Add rk3588-easepi-r2.dts
ifroncy01
requested review from
CodeChenL,
ColorfulRhino,
HeyMeco,
JohnTheCoolingFan,
SuperKali,
TheSnowfield,
Tonymac32,
ahoneybun,
amazingfate,
brentr,
catalinii,
chainsx,
efectn,
ginkage,
iav,
igorpecovnik,
joekhoobyar,
krachlatte,
lanefu,
paolosabatino,
prahal,
rpardini,
schwar3kat,
sputnik2019 and
vidplace7
as code owners
🚫 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. |
|
OLED Go should probably be maintained outside of armbian/build. Can you please add a summary for its purpose? |
- Move OLED Go source to separate github.com/ifroncy01/easepi-oled-daemon repo with GitHub Actions release workflow for prebuilt arm64/amd64 binaries - Remove golang-go host dependency (no longer needed) - Replace in-tree Go compilation with curl download from GitHub Releases - Remove `|| true` error masking on systemctl enable, chmod, and symlink operations to surface real errors during image build - Clean up `|| true` in bluetooth-hciattach script: log warning instead The OLED daemon (SSD1306 128x32, I2C on /dev/i2c-3) is now maintained separately with proper CI/CD, versioning, and release artifacts.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (1)
extensions/easepi-a2-peripherals.sh (1)
640-641:⚠️ Potential issue | 🟠 Major | ⚡ Quick winDon't enable
oled.servicewhen the OLED binary was allowed to go missing.The warning-only path above still reaches this unconditional enable, so the image can boot with
ExecStart=/usr/local/oled/oledpointing at a nonexistent file. Either fail the build on download errors or guard this enable step with an executable check.Based on learnings: In the Armbian build framework, scripts run with set -e, so failures that must be tolerated should be handled explicitly instead of leaving later critical steps unchecked.
🤖 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 `@extensions/easepi-a2-peripherals.sh` around lines 640 - 641, The script unconditionally enables oled.service via chroot_sdcard even when the OLED binary (/usr/local/oled/oled) may be missing due to a warned download failure; modify the flow so you either (A) make the download failure fatal (stop the build when the OLED binary download in the earlier step fails) or (B) guard the enable call by testing for the OLED executable before enabling the service (e.g., check that /usr/local/oled/oled exists and is executable) and only run chroot_sdcard systemctl enable oled.service when that check passes; update the logic around the download step and the chroot_sdcard enable to use one of these two approaches so the image never enables a service pointing at a nonexistent ExecStart.
🧹 Nitpick comments (1)
config/boards/easepi-a2.conf (1)
1-1: ⚡ Quick winMake the board description match the actual hardware.
This comment is shown in interactive build flows, so it should mention the A2's distinguishing features as well, not just the generic SoC/storage baseline. Please include at least the onboard Wi‑Fi/BT, OLED/IR, and 2.5GbE/NVMe-relevant hardware summary here.
Based on learnings: In Armbian board configuration files, the first-line comment should describe the hardware accurately, including SoC model, RAM options, and key features.
🤖 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/easepi-a2.conf` at line 1, Update the first-line comment in easepi-a2.conf so it accurately describes the A2 board hardware: mention the Rockchip RK3568 SoC (quad-core), RAM option(s) (e.g., 4GB), onboard Wi‑Fi/BT, built-in OLED and IR sensor, 2.5GbE port and NVMe support, plus eMMC and USB3 — replace the generic comment line "# Rockchip RK3568 quad core 4GB SoC GBe eMMC USB3" with a single-line summary that includes these distinguishing features.
🤖 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 `@extensions/easepi-a2-peripherals.sh`:
- Around line 602-612: Replace the unpinned download of the OLED Go binary and
blind curl install by pinning OLED_RELEASE_URL to a specific release asset
(e.g., include the release tag in the URL), download the corresponding published
SHA-256 checksum file for that exact asset, compute the local SHA-256 (via
sha256sum or similar) and compare it to the published checksum, and only install
(chmod +x and write to "${SDCARD}/usr/local/oled/oled") if the checksum matches;
update the display_alert calls to report the specific release tag and to error
out (and skip install) on checksum mismatch. Use the existing OLED_RELEASE_URL
and the target path "${SDCARD}/usr/local/oled/oled" as the identifiers to
modify.
---
Duplicate comments:
In `@extensions/easepi-a2-peripherals.sh`:
- Around line 640-641: The script unconditionally enables oled.service via
chroot_sdcard even when the OLED binary (/usr/local/oled/oled) may be missing
due to a warned download failure; modify the flow so you either (A) make the
download failure fatal (stop the build when the OLED binary download in the
earlier step fails) or (B) guard the enable call by testing for the OLED
executable before enabling the service (e.g., check that /usr/local/oled/oled
exists and is executable) and only run chroot_sdcard systemctl enable
oled.service when that check passes; update the logic around the download step
and the chroot_sdcard enable to use one of these two approaches so the image
never enables a service pointing at a nonexistent ExecStart.
---
Nitpick comments:
In `@config/boards/easepi-a2.conf`:
- Line 1: Update the first-line comment in easepi-a2.conf so it accurately
describes the A2 board hardware: mention the Rockchip RK3568 SoC (quad-core),
RAM option(s) (e.g., 4GB), onboard Wi‑Fi/BT, built-in OLED and IR sensor, 2.5GbE
port and NVMe support, plus eMMC and USB3 — replace the generic comment line "#
Rockchip RK3568 quad core 4GB SoC GBe eMMC USB3" with a single-line summary that
includes these distinguishing features.
🪄 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: 7137dc46-7ec3-4386-8c93-268c1577bfd6
📒 Files selected for processing (2)
config/boards/easepi-a2.confextensions/easepi-a2-peripherals.sh
- Download and verify SHA-256 checksum alongside the binary for supply chain security and reproducible builds (CodeRabbit review) - Guard oled.service enablement: skip if binary download/verification failed, preventing broken service on resulting image - Use OLED_BINARY_OK flag to communicate download status between pre_customize_image__ and post_customize_image__ hooks
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (1)
extensions/easepi-a2-peripherals.sh (1)
605-610:⚠️ Potential issue | 🟠 Major | ⚡ Quick winPin the OLED asset instead of using
releases/latest.Fetching both the binary and its checksum from
releases/latest/downloadstill leaves this image non-reproducible, and upstream can change between the twocurlcalls. Pin a concrete release tag and verify that exact asset instead.Suggested hardening
- local OLED_BASE_URL="https://github.com/ifroncy01/easepi-oled-daemon/releases/latest/download" + local OLED_RELEASE_TAG="vX.Y.Z" + local OLED_BASE_URL="https://github.com/ifroncy01/easepi-oled-daemon/releases/download/${OLED_RELEASE_TAG}" local OLED_BIN_NAME="oled-linux-arm64"🤖 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 `@extensions/easepi-a2-peripherals.sh` around lines 605 - 610, Change the downloads to use a pinned release tag instead of releases/latest by updating OLED_BASE_URL (and/or OLED_BIN_NAME) to include the concrete tag string, download both the binary and its .sha256 from that tag, and then verify the binary against the downloaded checksum before installing; specifically modify the block that defines OLED_BASE_URL/OLED_BIN_NAME and the curl lines that fetch "${OLED_BASE_URL}/${OLED_BIN_NAME}" and "${OLED_BASE_URL}/${OLED_BIN_NAME}.sha256" so they reference the pinned tag and add a checksum verification step (e.g., sha256sum -c or comparable) to ensure the asset matches the exact release before proceeding.
🤖 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 `@extensions/easepi-a2-peripherals.sh`:
- Around line 609-622: The checksum is written to a hardcoded /tmp/oled.sha256
which can collide in parallel runs; change the code to create a unique temp file
(e.g., OLED_SHA_FILE="$(mktemp)") before downloading the checksum, use that
variable instead of /tmp/oled.sha256 when extracting EXPECTED_SUM and when
removing the file, and ensure the temp file is removed on all paths (success or
SHA mismatch) — update the curl target, the EXPECTED_SUM extraction, and the
final rm -f to reference OLED_SHA_FILE so display_alert, OLED_BINARY_OK, and the
chmod logic remain unchanged.
---
Duplicate comments:
In `@extensions/easepi-a2-peripherals.sh`:
- Around line 605-610: Change the downloads to use a pinned release tag instead
of releases/latest by updating OLED_BASE_URL (and/or OLED_BIN_NAME) to include
the concrete tag string, download both the binary and its .sha256 from that tag,
and then verify the binary against the downloaded checksum before installing;
specifically modify the block that defines OLED_BASE_URL/OLED_BIN_NAME and the
curl lines that fetch "${OLED_BASE_URL}/${OLED_BIN_NAME}" and
"${OLED_BASE_URL}/${OLED_BIN_NAME}.sha256" so they reference the pinned tag and
add a checksum verification step (e.g., sha256sum -c or comparable) to ensure
the asset matches the exact release before proceeding.
🪄 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: 96d8a9fb-812e-47ed-bc0d-9a27d45bf71d
📒 Files selected for processing (1)
extensions/easepi-a2-peripherals.sh
|
@HeyMeco @EvilOlaf Thanks for your valuable feedback! I have completely refactored the workflow based on your suggestions: The required board assets and logos are currently pending in armbian/armbian.github.io#317. Once that asset PR is merged, the CI check here should turn green automatically. |
|
I don't understand what all these dtsi files are for. Some of this stuff is probably upstream already and (if it is expected that these boards will never hit upstream), why not simply putting a full device tree for each into the dt folder/s? About vendor kernel: We maintain our own version of kernel sources so you may want to send directly here: https://github.com/armbian/linux-rockchip instead of using a patch
All of rabbits concerns must be addressed or dismissed. |
|
#Hi @EvilOlaf,Thank you for the detailed feedback regarding architecture and maintenance. |
|
Since the extensions are board specific in this case it probably makes sense to keep them inside the board config too instead of separate. |
|
Not much more from my side. |
|
I will integrate the extensions into the board configuration and monitor the review status of the linux-rockchip PR. |
- Move easepi-a2-peripherals extension into easepi-a2.conf - Move easepi-r2-peripherals extension into easepi-r2.conf - Remove standalone extension files - Refactor rk3568-easepi-a2 device tree structure - Fix OLED binary download and verification - Clean up DTS patches and drop edge target
🚫 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. |
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
3 participants
#Description
This PR adds official Armbian support for two EasePi IoT gateway/NAS devices:
Changes (42 files, 11,914 lines):
config/boards/easepi-a2.conf,config/boards/easepi-r2.conf)patch/kernel/rk35xx-vendor-6.1/dt/)patch/kernel/archive/rockchip64-6.18/dt/)patch/u-boot/legacy/u-boot-radxa-rk35xx/)patch/u-boot/v2025.10/)extensions/easepi-a2-peripherals.sh,extensions/easepi-r2-peripherals.sh)https://github.com/ifroncy01/easepi-oled-daemon)config/kernel/linux-rk35xx-vendor.config)Dependencies:
rk35xxandrockchip-rk3588board familiesrockchip64LINUXFAMILY viarockchip64_common.incpost_family_config__hookDocumentation Summary
./compile.sh BOARD=easepi-a2 BRANCH=currentor./compile.sh BOARD=easepi-r2 BRANCH=vendorHow Has This Been Tested?
All builds:
BUILD_MINIMAL=yes BUILD_DESKTOP=no KERNEL_CONFIGURE=no ARTIFACT_IGNORE_CACHE=yesChecklist
File Statistics
Kernel Sources
https://github.com/armbian/linux-rockchip.gitrk-6.1-rkr5.1https://git.kernel.org/.../stable/linux.gitlinux-6.18.yhttps://github.com/torvalds/linux.gitv7.1-rc3Summary by CodeRabbit