Nothing so far. We are currently busy with some other projects.
I too feel bad when Zero 2’s support is mainlined but we couldn’t release it. This is the first board I brought up in Radxa.
I can’t make any promise now since my own schedule is full. Hopefully by mid year I’ll have time to revisit Zero 2 (along with Zero) if we still haven’t already done anything to it…
Following this since I’m also very interested in this project.
Fingers crossed it will be released.
Did you manage to revisit the zero2 lately? Look forward still
Currently working on ZERO 2 and it should be released soon.
The latest development build is using Debian 12 and Wayland already.
That is really great to hear. Currently we do need it for USB3, wifi, and 2 x UART (non debug port) connectivity.
I would assume * UART_AO_A (/dev/ttyAML0) is the debug port? what is the default baud rate?
How should I enable UART_AO_B, UART_EE_C or are they already enabled by the current OS release?
Thanks!
Sorry if this is a stupid question but wondering if this board could be connected / used thus:
Using a single cable connecting it to a (Windows) PC which both powers the Zero 2 and enables the host computer to detect it as an Ethernet adapter (ex. using “Responder”).
Since the board has:
1 x USB 2.0 Type-C OTG & Power combo port
1 x USB 3.0 Type-C HOST
I guess the USB 2.0 offers power but the actual host connection is through USB 3.0 so I would need two cables, one to connect it to the host and one to power it?
Update:
Basically to do what I can do with this:
PopStick™ - a USB Computer
with the Zero 2
In USB terminology, “host” is generally the device that uses the “device” device. Since you want your PC to use Zero 2 as an Ethernet, you should not connect Zero 2’s USB 3.0 Host port to your PC.
Instead, you should use the OTG port, which generally means the port can be either “host” or “device”. Since this is also the power port, you can use it like PopStick, with 1 cable providing both power and USB Ethernet connection.
BTW Zero also support this use case.
It seems Zero2 still using AP6256 without RSDB。
So, for the time being it seems like this magnificent board will not Grace the end user correct? Just when might it? Because this seems like a wonderful piece of technology that I can’t wait to get my hands on just to be able to run source games on it because there is a decomp or rather fixed to the leak that happened in 2020 to the source engine that allows you to run games like portal, half life 2 and the sorts natively on Arm based devices. But that’s what I’d use mine for, maybe some emulation here and there but that’s what I’d use it for.
I have a project in mind that might be a bit iffy for the Radxa Zero, but the Zero2 could definitely handle. So I could not be more excited for the release if it’s not tooooo far off:D
Any updates regarding the release date / availability? 
Currently blocked by last-minute Wi-Fi issue.
Is this the same speed issue as experienced with the mainline kernel/ drivers used by the Armbian guys?
I have not heard that. Can you link it for me?
From our end we have both some speed issue as well as firmware-induced issue as our version is provided by Infineon.
Not with the Armbian image (have not tried it yet), I used the Armbian kernel and u-boot to build the Volumio version and noticed the speed won’t go higher than around 180-200Mbit, hald thr speed of the zero version.
Any update on when the Zero 2 will be available for sale? I know it’s already available on Allnetchina but they only have the 16gb model at the moment and the 128gb model (the one I would buy) it’s not even listed…
We tried to get spdif working on rockpi 4b, but failed (at first).
It seems the default pin 15 (GPIO4_C5) has some sort of pulsing signal (looks like heartbeat) on it.
So we replaced the pinctrl-0 setting for spdif and created an overlay for it:
/dts-v1/;
/plugin/;
/ {
fragment@0 {
target = <&spdif>;
__overlay__ {
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <&spdif_bus_1>;
};
};
};
SPDIF is now on pin 32 (GPIO3_C0) and works fine.
An issue you could help me with in return 
Thanks,
Gé
This is because the same power domain is used to power the status LED:
You could turn off the status LED in rsetup, and that should remove the interference.
Sorry, I went off-topic here my apologies.
Anyway, with the overlay for pin 32 (GPIO3_C0), spdif rocks, no need to use the default one.
