Rockchip RK3588M is an automotive-grade variant of the Rockchip RK3588 octa-core Cortex-A76/A55 SoC that supports at least 6 Full HD displays and 16 camera inputs and can simultaneously run the car dashboard, in-vehicle infotainment, a digital rearview mirror, headrest monitors, ADAS system, and more.
The frequency of the Cortex-A76 cores is limited to 2.1 GHz, and the Cortex-A55 cores to 1.7 GHz, against 2.4 and 1.8 GHz for RK3588, probably to operate in a larger temperature range required by the automotive market. I could not find any RK3588M datasheet yet, but we can find more details through the Firefly AIO-3588MQ automotive mainboard built around the RK3588M processor.
Firefly AIO-3588MQ specifications:
- SoC – Rockchip RK3588M octa-core processor with
- CPU 4x Cortex-A76 cores @ up to 2.1 GHz, 4x Cortex-A55 cores @ up to 1.7 GHz
- Arm Mali-G610 MP4 GPU with OpenGL ES 3.2, OpenCL 2.2, Vulkan 1.1 support
- 6 TOPS AI accelerator
- Video decoding:
- 8Kp60 H.265/VP9/AVS2
- 8Kp30 H.264 AVC/MVC
- 4Kp60 AV1
- 1080p60 MPEG-2/-1/VC-1/VP8
- Video encoding – 8Kp30 H.265 / H.264
- Up to 32-channel 1080p30 decoding and 16-channel 1080p30 encoding can be achieved.
- System Memory – 4GB, 8GB, or 16GB (Up to 32GB optional) 64-bit LPDDR4/LPDDR4x/LPDDR5
- Storage – M.2 SATA3.0 SSD (2242), microSD card slot
- Video Output
- HDMI 2.1 up to 8Kp60 or 4Kp120
- DisplayPort 1.4 up to 8Kp30fps (via USB-C)
- VGA up to 1080p60
- eDP1.3 connector up to 4Kp60Hz
- 2x MIPI DSI display interfaces up to 4Kp60
- Up to 6 independent displays
- Video Input
- Dual 16M ISP on RK3588M
- HDMI input up to 4Kp60 with support for HDCP 2.3
- 30-pin MIPI-CSI(0) connector configurable as 1x 4-lane or 2x 2-lane
- Board-to-board connector with 4-lane MIPI_CSI(1) or 2x 2-lane MIPI-CSI(1) + 2x MIPI_D/C (4-lane DPHY v2.0 or 3-lane CPHY V1.1)
- Audio
- 3.5mm audio jack
- Digital audio output via HDMI 2.1 and DP 1.4 ports
- Line-in via header
- Microphone input
- Networking
- 2x Gigabit Ethernet RJ45 ports
- 2.4GHz/5GHz dual-band WiFi 6 (802.11a/b/g/n/ac/ax), Bluetooth 5.0
- Optional 4G LTE/5G cellular
- USB – 4x USB 3.1 Gen1, 1x USB Type-C (OTG/DP1.4) port, and 3x USB 2.0 (via pin header)
- Serial – 2x RS232, RS485, CAN Bus
- Expansion
- 4-lane PCIe 3.0 slot
- mPCIe and M.2 sockets for wireless modules
- 20-pin 2mm-pitch header with GPIO, ADC, SPI, I2C, LED, REV, PWR, RST
- Power Supply – 12V DC / 2A recommended via 5.5/2.1mm DC jack or 4-pin header
- Power Consumption
- Idle – About 0.72W (12V/60mA)
- Typical – About 2.4W(12V/200mA)
- Max – About 14.4W(12V/1200mA)
- Dimensions – 146 x 102 x 37.5mm
- Weight – Around 200 grams
- Temperature Range – Operating: -40°C to 85°C in product page but -20°C to 60°C in the board’s datasheet
- Humidity – 10%80 % (storage)
The company offers support for Android 12.0, Ubuntu Desktop and Server, Debian 11, and buildroot RTLinux for the board//system-on-module. Firefly also mentions Kernel-based Virtual Machine
(KVM) and Docker container support, as it will be necessary to support critical (e.g. dashboard) and non-critical (e.g. infotainment) parts of the software with isolated and likely different operating systems. Technical documentation can be found in the Wiki to get started with Android, Linux, and RTLinux.
The first time I found out about the RK3588M was in a demo last February at the RKDC (Rockchip Developer Conference) showing a system driving four independent displays and two gamepads.
#RK3588M as car play/entertainment system. Single chip drives 4 individual screens and 2 gamepads. pic.twitter.com/dz70oxMaQb
— BG5USN (@BG5USN) February 24, 2023
Firefly is selling samples of the AIO-3588MQ automotive-grade AI mainboard on its store for $539 with 8GB RAM and 32GB flash, and $759 in 16GB/128GB configuration. Additional information may also be found on the product page.
Jean-Luc started CNX Software in 2010 as a part-time endeavor, before quitting his job as a software engineering manager, and starting to write daily news, and reviews full time later in 2011.
Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress
> frequency of the Cortex-A76 cores is limited to 2.1 GHz … probably to operate in a larger temperature range
Maybe this is simply the ‘sweet spot’ balancing consumption and CPU performance. When looking at RK3588(s) DVFS settings we see ‘high quality’ silicon variants able to reach the 2.2 GHz at just 912.5 mV so this combined with binning and reserving the best wafer output for RK3588M might allow clocking at 2.1 GHz with (significantly?) less than 900 mV.
> clocking at 2.1 GHz with (significantly?) less than 900 mV
RK started with defining 1.7/2.1 GHz DVFS OPP for RK3588M but in the meantime the only difference to RK3588(s) is deleting the highest cpufreq OPP which ends up with the A55 ‘maxing out’ with 1.6 GHz at 787.5 mV and the A76 with 2.0 GHz at 837.5 mV. As such the 1.7/2.1 GHz might be outdated info or just binning + PVTM at work resulting in actual clockspeeds being slightly higher than cpufreq OPP definition.
Silicon vendors like NXP usually have commercial-grade parts clocked higher than their equivalent industrial/automotive-grade parts, so I just assumed it was the same for RK3588M.
The result seems to be the same anyway but at least with RK3588 the differentiation seems to happen by binning (reserving best wafer output for RK3588M), PVTM and maybe SoC ID (RK3588M being slightly frequency capped). End result is RK3588M providing a little less CPU performance at way less consumption/heat compared to lower quality RK3588 variants that end up as RK3588 and mostly RK3588s.
but maybe they provide stable frequencies. The biggest difficulty as you’ve noticed with RK3588 is to get the desired frequency as it can go higher than desired based on PVTM, which is quite annoying in certain circumstances.
Well, I wouldn’t call the PVTM behaviour a difficulty and I’ve no idea where this would be annoying other than drawing wrong conclusions based on benchmark scores…
And I guess the CPU cores are the least interesting thing with RK3588M anyway since all the other IP blocks (camera inputs, displays, IPU/ISP, VPU, GPU and so on) are way more important for the use case.
It’s annoying in that there’s no way to respect a given frequency. Variations in the range of +/-5% between samples can be a problem for some use cases. For example when I’m developing and trying to measure some differences of efficiency between different approaches, it’s common for me to limit my CPU’s frequency to one that remains stable over the test, otherwise it’s easy to get fooled by wrong measurements. Here you boot once and you’re at 2.1 GHz, you boot a second time later you’re at 2.2, it gets hot and you’re back to 2.1 etc. It’s very hard… Read more »
> It’s very hard to draw conclusions about anything in such a case
Sure, that’s the ‘drawing wrong conclusions’ issue I mentioned above. Who is affected by this? You, me and maybe another 98 persons on this planet. So essentially a non-issue. 🙂
As for ‘higher frequency than configured’ I’ve seen this also with few Qualcomm SoCs and x86 CPUs (Linux’ cpufreq settings being more or less irrelevant).
I overlooked that the 1.7 GHz DVFS OPP has been added to rk3588s.dtsi which all RK3588 variants rely on as such it’s still there with RK3588M.
But it doesn’t matter that much since as long as Rockchip’s BL31 BLOB is in charge of bringing up the SoC the whole PVTM thing is a black box anyway and the MCU inside the SoC does completely its own thing (just recently confirmed again).
Back in a day, when I was installing mission-critical workstations in remote police departments, I downclocked the hell out of them just to make sure they will work no matter how hot they will be or what amount of tobacco smoke will form a residue on CPU’s radiator.
I knew those vandals will smoke in front of my equipment, and I had no sympathy to them whining about low performance.
Did that as well the late 90s for sales people PCs which were mostly used with ms-office at a time where all the processing time was dominated by 1) keyboard, and 2) disk access time. This way when the Pentium’s fan started to make a loud vibrating noise, it was sufficient to unplug it and the machine could still run reliably:
Interesting how we get 16 camera inputs, RK3588 datasheet states 6 MIPI CSI2 inputs? Anyway another claim “Up to 32-channel 1080P@30fps decoding”, so tried decoding 14 H264 + 2 H265 streams … seems to work .
> tried decoding 14 H264 + 2 H265 streams … seems to work .
Impressive! Do you have a consumption figure for this?
I’d need to get hold of a power meter to measure consumption figures. Overall CPU load is surprisingly low though.
> Overall CPU load is surprisingly low though.
Oh yes, your demo video shows this clearly starting at 0:48 🙂
In case you repeat the test I would love to know whether output of this (as root ofc) changes comparing no vs. full VPU acitivity:
For some reason can’t reply to last post, no change ‘no vs full VPU activity” no VPU root@rock-5b:~# grep clk_vpu /sys/kernel/debug/clk/clk_summary aclk_vpu 0 4 0 396000000 0 0 50000 hclk_vpu 0 4 0 198000000 0 0 50000 123 root@rock-5b:~# grep clk_vpu /sys/kernel/debug/clk/clk_summary aclk_vpu … Read more »
> For some reason can’t reply to last post
My last comment has been flagged as whatever and Jean-Luc obviously was busy with real life instead of running the blog 🙂
As for the clk_summary I don’t think GPU and VPU share something (since Mali/ARM vs. Rockchip IP but honestly I’m pretty much clueless in this area).
There is also RK3358M and RK3568M.
Supposedly the RK3568M is not pin to pin compatible with the RK3568 so I wonder what differs (no datasheet for this one).
RK3588M is due to receive QNX and Android Automotive support this year with Rockchip strongly pushing automotive scene.
I’m interested in the RK3568M but there’s limited information out there, if anyone happens to be working with a supplier that is – please let me know!
Please contact [email protected]