NanoPi Zero2 support

[rollinglabs]

Hi Armbian Community,

I'm creating a board configuration for NanoPi Zero2 (RK3528A) and wanted to coordinate with the community before submitting.

 

Great News: Mainline Support Exists!

I discovered that Jonas Karlman has already merged NanoPi Zero2 device tree support into mainline Linux kernel:

• Device tree: rk3528-nanopi-zero2.dts (merged for v6.15-6.18)
• U-Boot support: Also merged
• Source: https://github.com/ziyao233/rk3528-mainline

Since the hinlink-h28k.csc config already provides RK3528 support, creating a NanoPi Zero2 config should be straightforward.

 

Quick Questions

1. Is anyone already working on this? (Don't want to duplicate!)
2. Kernel branch: Should I target current (6.12) or edge (6.15+) for the DTB?
3. Bootconfig: Can I reuse hinlink_rk3528_defconfig or does Zero2 need its own?

 

My Plan
  # Copy existing RK3528 config
  cp hinlink-h28k.csc nanopi-zero2.csc

  # Update:
  BOARD_NAME="NanoPi Zero2"
  BOOT_FDT_FILE="rockchip/rk3528-nanopi-zero2.dtb"
  KERNEL_TARGET="current,edge"

 

Testing Commitment

• Hardware: NanoPi Zero2 arriving next week
• Use case: Production IoT device (headless, Docker, eMMC boot)
• Will test: Full manufacturing flow, LED control, eMMC boot, network, Docker
• Will contribute: Tested config + documentation

 

Why This Board?

Tiny form factor: 40×40mm
Production-ready: Good margins, reliable supply
Sufficient specs: 2GB RAM, eMMC, single GbE
Mainline support: Thanks to Jonas Karlman's work!

 

Any advice before I proceed? Happy to collaborate or take guidance from maintainers. Thanks! 🙏
 

Edited October 31 by rollinglabs

[Werner]

Even though current is an LTS kernel it probably makes more sense to focus on vendor an edge. vendor because its rockchip bsp and close to being feature-complete. And edge for likely becoming the next LTS kernel which ultimately become current at some point.

You can try to see what actually works on current at this time.

You can ignore 6.15-6.17 since those patches, if still present, are for archival purposes only and will be remove at some point.

 

4 hours ago, rollinglabs said:

Bootconfig: Can I reuse hinlink_rk3528_defconfig or does Zero2 need its own?

In theory it could be re-used but may introduce confusion. If in doubt, copy and rename.

 

Edit: Seems like lots of stuff has been mainlined already. So I suggest shifting your primary focus on edge.

[PaulViks]

hi, @rollinglabs

Have you already had a chance to play with it SBC?

[rollinglabs]

Hi everyone, wanted to share what we found attempting Armbian support for Zero2.

• Zero2 utilises an Android-style partition layout from FriendlyElec, which I found to be fundamentally incompatible with Armbian's partition scheme. It seems to use an Android layout (boot at partition 4, rootfs at partition 8, etc.) vs Armbian's standard GPT layout.
• U-Boot is configured to look for partitions at specific Android-style locations
• Zero2 assigns SD=mmcblk0, eMMC=mmcblk2 (opposite of typical RK3528 boards)

What I think is needed:

• Adapt hinlink_rk3528_defconfig for Android partition layout
• Modify partition table generation in the Armbian build system
• Update bootloader scripts to match partition locations
• Handle the inverted mmcblk device assignments

• LED mapping adjustments (Zero2 uses 2-LED system: sys_led, user_led vs typical 3-LED RK3528 boards)

• Network interface detection (single ethernet vs dual on R3S/hinlink)

The device tree is already merged (rk3528-nanopi-zero2.dtb - thanks Jonas!), so that part is straightforward. It's specifically the bootloader/partition integration that's the blocker. Would love to hear thoughts.

 

For now as a workaround, we've stayed with FriendlyElec's Ubuntu base to keep our project moving.

[eselarm]

I have the NanoPi-R6C and that came out of the box with an OpenWRT variant on eMMC. Indeed many partitions, but I think I managed to get it running somehow with Debian/Armbian rootfs on some higher partition number, I don't remember exactly. As long it can load boot.scr. Indeed eMMC is number 2, I guess they avoid potential confusion that is sometimes there with SBCs and various OSses swapping numbers for SD-card and eMMC. I had that once, no data loss but costed a lot of time. It is a bit similar to that on 6-SATA PC's, Debian might name the OS dev (SSD) /dev/sdb and a large HDD /dev/sda while Opensuse names OS always /dev/sda. So what do we do with 2-MMC SBC's ?

 

I see my HP x86-64 dualrole computer/tablet uses /dev/mmcblk1 (its eMMC) for OS (Linuxes at least, Windows10 I don't remenber). The SD-card slot I have normally empty but uses /dev/mmcblk0 if card is inserted. It has UEFI and SecureBoot and TPM, so no choice actually like there is with opensource U-Boot.

 

For NanoPi-R6C I have written Tianocore EDK2-UEFI to eMMC and appears as /dev/mmcblk1. I do not use the rest of the 32GB storage, but the UEFI binary comes with 1 partition, so easy to use the rest of the 32GB, but currently I need the much larger and faster NVME. And for emergency, if I insert an SD-card with newly generated rolling/edge image or so, it boots from that and is then /dev/mmcblk0. So this is IMO the preferred numbering, but I already had created some shell script code that can identify the boot partition and the root partition, but it is not too generic, only works if certain mounts are there which is what I have as I focus on EFI bootable and Btrfs with subvolumes ('nested' and default).

 

So I would at least use 0 for SD. 1 for eMMC is fine.

 

For the LEDs, on my NanoPi-R6C, I actually don't know, I never look at them. I think it is not correct with my installation (in-place upgraded and also other Linuxes), but I guess correct with current downloadable images. At least they were correct with the FriendlyElec OpenWRT that was pre-installed. I still can't get maskROM mode to work, so I am a bit paranoid on messing too much with data in the Rockchip loader area. I am not sure what happens if I put rubbish data or broken U-Boot there, can I still start from SD-card is the question. I might need to apply a fixed voltage between 9-20V as powersupply, but need to look in PCB schematics again first.

 

For the Zero2,  I see removable eMMC, so no risk or fear for 'hard-bricking'. Although I would check if maskROM works. For network, I assume it is the on-SoC port, so fixed off-the-shelf, so end0 is fine. For optional WLAN, I am not sure, likely some PCIe/HWtree named string, I have seen multiple altnames for 'wlo1', at least 'wlp1s0' or 'wlx<MACaddress>'. systemd-networkd should be able to handle those, NM can do all anyway.
 

Edited 20 minutes ago by eselarm