@hipboi any idea what power inputs this will support?
For instance would 5V 2/3 A be enough?
Introduce ROCK 5B - ARM Desktop level SBC
I think we should reserve 15W for CPU, 9W for USB 3.0, 5W for USB 2.0,10W peak for SSD. So 65W should be enough for full peripheral at full load.
For normal usage, I think 24W should be enough, 12V/2A.
There is no barrel jack on this board so we need to use USB-C with USB PD. Does the USB PD circuitry support QuickCharge 4.0 AKA USB PD 3.0 with flexible power rules or are we stuck with power profiles? If the latter it looks like:
- Profile 4 for 60W (20V/3A)
- Profile 5 for 100W (20V/5A) but needs 5A rated cables
For 65W… is there a way to do this with 3A PSUs/cables?
Hey guys, I already bought the discount coupon, really hoping this SBC is going to be awesome
I would like to ask someone from the team:
What’s the situation with GPU/VPU drivers for linux going to be? I have a rockpi 4c and gotta say, there’s no good solution to have a linux desktop with GPU-accelerated video (there’s a patch for armbian with legacy kernel, even that is kind of hacky and the legacy armbian has weird issues with HDMI), i’ve tried like 4 different distros – it’s either old kernel and patched (hence updates held back) packages or current kernel and no VPU support (because the patches, afaik, were a one-time community effort)
Is RK3588 going to be an improvement, VPU-support-wise? I mean, like, set up a distro like armbian or manjaro and have Firefox play 4k youtube accelerated, have mpv/vlc/kodi use the GPU properly, and all that.
Cheers, thanks in advance <3
Yes it is confirmed
PCIe 3.0 can be bifurcated to 1x4lanes, 2x2lanes, 4x1lane and 1x2lanes + 2x1lane
it can operate with Root Complex and End Point.
Please wait for official confirmation from radxa until rk releases the full specification and what all is utilised by the vendor.
In ARM GPU can only fo 2D and 3D rendering, Video is processes by VPU and sadly there is still not stable and robust support for this in any ARM device yet.
Hopefully with RK35xx series if RK can provided all this in uefi and then push the driver to linux driver then only it can be fully utilized. Till then we have to wait for team to reverse-engineer it which takes years to reach a stable stage.
Yeah, that would probably instantly put the RK35xx devices on top of everything in the media box world. So sad to see these powerhouses not living up to the full potential of the hardware bc of the whole closed binary driver package thing. So far it’s either “get an apple tv” or “get a highly vendor-customized android box and hope the firmware is not total nightmare”
Sad, as RK3588S may not cut it: yes it has two PCIe 2.0 x1, but I don’t think it would be “sufficient”, say if we want to make a more flexible platform. Really recommend a bigger CM5 based on RK3588 instead, and consider carrier boards in the size of (better be exact for “compatibility”, as Rock 5 is a bit wider at 72 vs. 69.85)
- 3.5" HDD (147x101.85), and 2) 5.25" ODD (203x146)
With these carry board sizes, it should have enough space to put “everything” back that was left out because of 5’s limited size (e.g. 2xGbE). Say, one can even create a 8-port “router” if the carry board has PCIe slots (PCIe 3.0 x4 for 2x10GbE, PCIe 2.1 x1 for 4xGbE, onboard 2xGbE => 8-port), or 16-ports NAS (x4 => 8-port HBA, 2x1 => 2*4-port HBA), or anything in between?
And of course, I know if Radxa keeps it “Pi CM4 compatible”, sales could be better perhaps, as I saw applications like TPU enabled surveillance etc. where RK3588S is more than sufficient.
Dumb 12V and 20V PS are supported.
QuickCharge 4.0 AKA USB PD 3.0
QC4.0 and PD 3.0 are different protocol, but many PS chips support both.
USB-C Power Delivery 3.0 (PD3.0) introduces a new Programmable Power Supply (PPS) mode, which allows a device to negotiate any supply of 3.3-21 V in 20 mV steps, and up to 5 A of current in 50 mA steps.
I think PPS is the flexible power rules you refer. It depends on the power adapter(the chip PD version and the PS output capability design, as far as I know, most PS doesn’t support PPS.
I believe the reason of PPS is the power loss rate, convert 9V to 5V is more efficient than convert 20V to 5V, so the more precise the PS output just enough power for the device(dynamic system power request from the PS), the less power wasted.
The USB C controller we use, fusb302 or alternative is PD 2.0 phy only. It can not support PPS.
For 65W, currently we are negotiating with the PS output 20V for sure.
So, how about that heatsink and fan? Cases?
Will it have an OTP Memory to punch in a public key for boot verification and a facility to verify the first bootloader? (Lockdown in general but for the actual owner.)
Does that SOC include any extra computers Intel ME style?
Does it have an undocumented boot by GPU mess like the rapsberries?
Does it have a hardware RNG? Is that one worth even thinking about?
Does it have a RTC?
Will it have an OTP Memory to punch in a public key for boot verification and a facility to verify the first bootloader? (Lockdown in general but for the actual owner.)
Yes, it has OTP.
Does that SOC include any extra computers Intel ME style?
There are three cortex-m0 mcu inside, not sure if all of them are for the big core control, i think the firmware will be open source.
Does it have an undocumented boot by GPU mess like the rapsberries?
Absolutely no.
Does it have a hardware RNG? Is that one worth even thinking about?
Yes, not sure about the driver status yet.
Does it have a RTC?
Yes, RTC battery connector is available on 5B.
I didn’t find any documentation regarding this. Are you sure?
I have seen some secure flag in the maskrom spi flashing tools code but nothing explains what that actually does. 1 bit of configuration flag isnt exactly a promising hint of finding signed boot facilities.
(For the 4)
So can you answer this question a bit more explicitly?
Wondering if any of the chips on the back is an SPI flash for a bootloader. And also, have you thought about implementing Embedded Base Boot Requirements (EBBR), which would be a killer feature for adoption.
I don’t see any mention of OTG support, is it not available on this board? Or an omission?
What is the benefit of using Radxa provided Debian Buster over regular Debian Buster?
Radxa’s Buster is some Debian userland combined with BLOBs (RAM initialisation, ‘firmware’ for at least one of the 3 included MCUs), bootloader and kernel from Rockchips’s BSP (board support package). It will boot.
“Debian Buster” is what the Debian project provides relying on mainline u-boot and mainline kernel and trying to be BLOB free.
RK3588 is a new SoC. There’s zero support for it in mainline u-boot and mainline Linux kernel so guess what you will get with “Debian Buster” --> the board will not even boot.
Video Output
Dual HDMI 2.1 / eDP up to 8Kp60 or 4Kp120
Dual DisplayPort up to 4Kp60
Dual MIPI DSI output
Up to four independent displays
Supossedly… But read the manual
Presume if hardware decoding ever gets a working driver then
1.2.4 Video CODEC
Video Decoder
Real-time video decoder of MPEG-1, MPEG-2, MPEG-4, H.263, H.264, H.265, VC-1,
VP9, VP8, MVC, AV1
MMU Embedded
Multi-channel decoder in parallel for less resolution
H.264 AVC/MVC Main10 L6.0 : 8K@30fps (7680x4320)②
VP9 Profile0/2 L6.1 : 8K@60fps (7680x4320)
H.265 HEVC/MVC Main10 L6.1 : 8K@60fps (7680x4320)
AVS2 Profile0/2 L10.2.6 : 8K@60fps (7680x4320)
AV1 Main Profile 8/10bit L5.3 : 4K@60fps (3840x2160)
MPEG-2 up to MP : 1080p@60fps (1920x1088)
MPEG-1 up to MP : 1080p@60fps (1920x1088)
VC-1 up to AP level 3 : 1080p@60fps (1920x1088)
VP8 version2 : 1080p@60fps (1920x1088)
Video Encoder
Real-time H.265/H.264 video encoding
Support up to 8K@30fps
Multi-channel encoder in parallel for less resolution
1.2.5 JPEG CODEC
JPEG Encoder
Baseline (DCT sequential)
Encoder size is from 96x96 to 8192x8192(67Mpixels)
Up to 90 million pixels per second
JPEG Decoder
Decoder size is from 48x48 to 65536x65536
Support YUV400/YUV411/YUV420/YUV422/YUV440/YUV444
Support up to 1080P@280fps, and 560 million pixels per second
Support MJPEG
1.2.11 Video Output Processor
Video ports
Video Port0, max output resolution: 7680x4320@60Hz
Video Port1, max output resolution: 4096x2304@60Hz
Video Port2, max output resolution: 4096x2304@60Hz
Video Port3, max output resolution: 1920x1080@60Hz
Cluster 0/1/2/3
Max input and output resolution 4096x2304
Support AFBCD
Support RGB/YUV/YUYV format
Support scale up/down ratio 4~1/4
Support rotation
ESMART 0/1/2/3
Max input and output resolution 4096x2304
Support RGB/YUV/YUYV format
Support scale up/down ratio 8~1/8
Support 4 region
Overlay
Support up to 8 layers overlay: 4 cluster/4 esmart
Support RGB/YUV domain overlay
Post process
HDR
HDR10/HDR HLG
HDR2SDR/SDR2HDR
3D-LUT/P2I/CSC/BCSH/DITHER/CABC/GAMMA/COLORBAR
Write back
Format: ARGB8888/RGB888/RGB565/YUV420
Max resolution: 1920x1080