Radxa launched their low cost ($40) Rock Pi 4 SBC powered by Rockchip RK3399 processor a little over 18 months ago. If you are subscribed to their mailing list, the company has now sent an email entitled “” (no link available) that reports about v1.4 of the board with 4MB SPI flash onboard, an external WiFi antenna connector, and various other small changes, as well as the announcement of RockPi PoE HAT to power the board from an Ethernet cable, and an USB 3.0 eMMC card reader.
But what particularly caught my attention in the email was a new tiny single board computer powered by Rockchip RK3308 Cortex-A35 processor: Rock Pi S selling for as low as $9.9 with 256MB RAM, and targetting headless IoT & smart voice applications.
Rock Pi S board specifications:
- SoC – Rockchip RK3308 quad-core Arm Cortex-A35 processor with built-in VAD (Voice Activity Detector)
- System Memory –
- Storage – microSD card for OS storage media, optional 1/2/4/8Gbit onboard NAND storage for cost saving
- Connectivity
- 100Mbps Ethernet with optional PoE (additional HAT required)
- Optional 802.11 b/g/n WiFi 4 + Bluetooth 4.0 (via RTL8723BS) with external antenna
- USB – 1x USB 2.0 OTG type-C port, 1x USB 2.0 host type-A port
- Expansion – 26-pin Pi GPIO header, 26-pin voice/audio header
- Power Supply – 5V via USB-C port
- Dimensions – 3.8 x 3.8 cm
The company reports the first batch of ROCK Pi S boards is tested and so far proved to be working all well. The board currently runs Debian and buildroot build system is supported. The company has some samples in the office, and interested developers can contact the company to get a sample.
Rock Pi S will sell for $9.9 and up with the cheapest model coming with 256MB RAM, and a microSD card socket for storage. AFAIK, there’s currently no product page nor other public information available online for the new Radxa board except for the newsletter’s email.
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
Let’s hope RK3308 is software compatible to PX30 which recently appeared on http://opensource.rock-chips.com/wiki_Main_Page
And let’s also hope there’s some SPI NOR flash on the board to allow for PXE booting later without any additional storage…
Yes, RK3308 is a stripped down version of RK3326 and RK3326 is a stripped down version of PX30.
For the cost sensitive IoT application, SPI NOR is kind of awkward because for small size(< 16MB), you basically can not do anything within it. For larger size(128MB), the cost is relatively high. What we choose on ROCK Pi S for storage is SD Nand, nand flash with SDcard interface, soldered on board, which offers 1Gb/2Gb/4Gb/8Gb options, perfect for an IOT Linux image. So the user don't need to waste the 16GB uSD card.
> SD Nand, nand flash with SDcard interface
With own controller (flash translation layer)? Or has wear leveling etc. happen at the software layer requiring appropriate flash filesystems?
Basically it’s SD card, but in a SOP8 footprint. So we don’t need the driver to handle the wear leveling etc, familiar sd card interface.
OK this can be a great solution then!
Funny how using SD card technology is bad in the context of RPi but other vendors follow the suit. Sure it’s a different package, but all Shenzhen RPi competitors used to provide SPI NOR and it was somehow better even without wear leveling.
> Funny how using SD card technology is bad in the context of RPi
How should it be bad? The main problem with SD cards is users not being aware of access patterns (sequential transfer rates being almost irrelevant on SBC but high random IO performance needed) and users again not being aware of counterfeit flash products faking higher capacities than real and therefore failing magnitudes faster than ‘real’ flash products.
With RPi and the actual limitation (only HS mode due to missing 1.8V SD card support) there’s some room for improvement and when next year the next RPi iteration will be presented doubling both sequential and random IO SD card performance due to then supporting also UHS-I/SDR104 this will be praised as a great invention.
Anyway: what Tom wrote above are Gb numbers so ‘ 1Gb/2Gb/4Gb/8Gb’ is 128MB-1GB in reality. Curious what they’ll charge for the variants and how they perform especially when it’s about random IO. And I still would want a few MB SPI NOR flash to be eventually able to boot and power such a board via network (PXE/PoE).
Well, the issue is more about device wear. Basically, you cannot have a swap partition, and many services which write rotary log files tend to damage SD cards within one or two months of simple IoT usage. Even USB sticks seem to have more durability and provide more performance.
Just have a look how we deal with this in Armbian: Of course no swap on SD card but swap to zram instead (works great!) and the armbian-ramlog service keeps logs compressed in RAM to flush them every hour to SD card therefore minimizing Write Amplification by magnitudes.
As for ‘performance’ I prefer A1 rated SD cards since they have to provide at least a minimum of random IO performance and there’s nothing comparable for USB sticks.
Talking about Armbian: do you know Armbian’s support plan for this ROCK PI S ? Not yet there on the Download page
I personally put a full fledge OS in 16 MB. And I’m sure many of us would love to have this because a 16 MB NOR isn’t that expensive. I bought 5 for a few bucks last year to upgrade small 8MB devices and work with ease.
>For the cost sensitive IoT application, SPI NOR is kind of awkward because for small size(you basically can not do anything within it.
16MB is enough for a single image with python etc. For “IoT” you don’t want your firmware to be much bigger than 16MB because it becomes impossible to do OTA updates once you get much bigger than that.
Nowadays people just don’t care. You’ll want a normal kernel with full initramfs that can boot from disk labels.. You’ll definitely want a full JS Node engine on the edge device. NPM will pull hundreds of dependencies. You’ll probably run it in Docker in the node. Docker will cache hundreds of megabytes of OS images. The whole Docker runtime is like 200 MB. Docker orchestration provides A/B updates. It’s 2019 baby.
>Nowadays people just don’t care.
They’ll care as soon as they try to update multiple devices all over the place. The most useful IoT stuff is going to be used in places that are hard to access and have marginal signal quality. Pulling hundreds of megabytes of packages, frashing your local storage to work out what to update and sometimes getting into a inconsistent state and bricking isn’t advantageous.
>It’s 2019 baby.
And almost all “IoT” devices in the wild are microcontroller based with firmware can be copied multiple times into a 8 or 16MB SPI NOR.
“It’s 2019 baby”
Embedded on 2019 means gigabytes of RAM and Flash.
Embedded in 1999 was more 1MB of flash and 4MB or RAM…
>Embedded on 2019 means gigabytes of RAM and Flash.
Even if that were the case it still wouldn’t overcome the barrier of getting a massive update down a poor connection. All the gigabytes of RAM in the world aren’t going to let you download anything bigger than a few megabytes over poor wifi or LoRa.
Nonsense.
“Embedded” has always included highly price-sensitive applications and it always will.
In 1999, an embedded device with more than 1MB and 4MB of RAM would have been something like a mid-range $500 desktop laser printer. It would have been a tiny fraction of the embedded devices on the market.
In 1999 devices with 1/10th as much RAM and flash would have been vastly more common. In fact, that’s probably still the case today.
Jerry, you are clearly in over your head, and you don’t know it. People have different use cases and chances are good, they understand them better than you do. Perhaps you can help me understand you use case.
Why is node.js (or is JS node something different that I’m not aware of?) necessary on the edge devices you deploy? Are you not concerned about the large attack surface? Are you not concerned about the other unknowns that often come with added complexity (and the costs that lurk with them)?
It’s 2019, but carefully managing costs and risks always has some value. It can be enough value to make the difference between an economically unviable niche, and a viable one. Which way things break really depend on the niche. With relatively low volume and relatively high margins, room to grow and flexibility pay off. You can always “tighten things up” later, if things take off (which is one scenario where people start worrying about the things that you dismiss).
Can you walk me through your thought process on the tradeoffs? It would help us understand where you are coming from. Thanks!
Took a glimpse into rockchip sources.
Most devices are already upstream, AFAICT
The documentation on Rockchip github page is useless.
The TRM on ROSA page are better
https://dl.radxa.com/rockpis/docs/hw/datasheets/
What about mainline kernel support for RK3308? Is it partially done at least?
Sure: https://www.cnx-software.com/?s=PX30+release
That looks nice. Good job.
But what is “SD Nand, nand flash with SDcard interface” ?
I agree SPI NOR would be nice, And eMMC (soldered or socketed) is better than SLC NAND which is better than MLC/TLC NAND.
SPI NOR / eMMC > SLC NAND > MLC/TLC NAND.
TL:DR MLC/TLC NAND is the worst.
Thank you.
I second this. Parallel NAND is a nightmare, stay far away from it.
SPI NOR is fine for booting from (and reading a compressed disc image that you unpack to RAM), but I wouldn’t try to put a normal filesystem on it–it’s too inefficient space wise.
eMMC and other SD type interfaces are good. But the quality of the connected device can vary a *lot*. I have uSD cards of the same size. One can do single digit I/O per second and the other can do >1K I/O a second. That makes a huge difference in performance of filesystems placed on it. If you’re just loading a compressed image from it, you’d be hard pressed to tell the cards apart.
>eMMC and other SD type interfaces are good.
One advantage SPI NOR has over those is that it’s incredibly simple and lots of SoCs now have a controller that memory maps everything and does the leg work. If the boot rom sets up the memory mapped controller you don’t even need a driver in u-boot to load your kernel and initramfs.
I would love to see a similar SPI NAND interface/controller block become more common.
Looks really nice except for the RTL wifi. If it’s meant for IoT then the RTL wifi is a show stopper.
Seems pretty close to this too: https://item.taobao.com/item.htm?spm=a230r.1.14.113.62062d11aiJtTx&id=595669877515&ns=1&abbucket=15#detail
> If it’s meant for IoT then the RTL wifi is a show stopper
Curios: why exactly?
>Curios: why exactly?
– Drivers are awful; AFAIK it’s a code blob straight from realtek dumped in the kernel. Driver + chip combination isn’t very stable which is no good if you have something out in the field. You don’t really want to have a script that checks if the wifi has locked up and reboots everything to get it back again.
– The drivers don’t do proper ap + station etc via the linux wifi sub-system with virtual interfaces. The only way to do it apparently is to enable a hack in the drivers that presents two interfaces. You want ap + station to do on boarding and recovery. Even the XR819 can do it. ;p
From your point, which wifi chip do you think is linux friendly? rtl8723 is the lowest cost wifi/bt chip we can buy on the market.
broadcom/cypress is the best; It can do virtual interfaces with station and ap, it can do custom information elements (needed for Apples WAC onboarding and useful to have to announce IoT devices), with the latest firmwares from cypress they are pretty stable.
The marvell chips are ok, they can do the station and ap stuff but custom IEs didn’t work last time I tried it. The drivers are a little bit unstable too.
If it needs to be super cheap though the xradio xr819 would work fine if someone could get the information out of allwinner to clean up the drivers.
You could use the Ampak module footprint. RTL8723 modules (¥12) are available in that footprint. Or the AP6255 (dual band + BT, ¥24) which we use. Now you can pick the wifi module you want.
There may be a BT only module in that footprint too.
Ampak is terrible though, it’s old Broadcom chips inside and half of them aren’t supported in Linux. And Broadcom’s Wi-Fi business for much of the Ampak chips was sold to Cypress is about to be devoured by Infineon…
I would expect zero support for any Ampak module that isn’t already supported and the ones that are, might not be around for much longer.
By the looks of things, soon there are no Linux friendly Wi-Fi options left.
What makes the ampak modules incompatible with the mainline driver assuming you have the right magic numbers files for them? I have the AP6212s and others working with the mainline driver + the latest firmware from cypress without any issues.
The firmware is apparently the same as what is shipped in their other drivers, IoT SDK etc. Assuming they don’t massively change the host interface for newer chips then there is no reason that the mainline driver won’t work with them.
Plenty of Ampak modules that there are no drivers for, such as the AP6356x, AP6359x, etc. i.e. anything 802.11ac 2×2.
On top of that, Ampak also seems to have changed around their model names on more recent modules, so they’re now WL3xx rather than AP6xxx….
On top of that, Cypress has discontinued about half of the Broadcom Wi-Fi chips found in these and other Ampak modules.
Those are supported in brcmfmac according to https://wikidevi.com/wiki/AMPAK
I found the board for sale at:
https://shop.allnetchina.cn/collections/frontpage/products/rock-pi-s?variant=29158789972070
But its sold out.
At least you can find a little more info about it and they state that “PRODUCTS WILL BE AVAILABLE IN SMALLER QUANTITIES AT THE BEGINNING OF JULY”.
OK. I can see the wireless module is optional, so the $9.90 board is without it. It goes to $15.99 with WiFi and PoE, 512MB RAM.
Wait a minute, RAM is only up to 1178Mbps? That slow? 1178MT/s sounds much more reasonable for DDR3
1178 Mbps does not seem right. I just remove that bit of info since I don’t know which unit they meant to use here.
I assume it’s 1178 Mbps per pin, i.e. 589 MHz.
Yess, finally a small SBC with a low price!
If it didn’t had Ethernet it would beven more perfect (for my needs)
If someone would create a som (with that low price) with a that small footprint i would buy it at day 0
What about NanoPi NEO Air? https://www.cnx-software.com/2016/09/28/friendlyarm-introduces-nanopi-neo-air-with-wifi-ble-camera-interface-and-8gb-storage-for-17-99/
Edit: I can see it’s $28 now…
The allwinner runs too hot for my needs,
If they will make a NanoPi Duo2 with 2 io rows, with rockips and emmc i would buy it.
I have to create a simple qt application to display stuff…
The NanoPi NEO Core2-LTS would be ok (only problem would be the the hot CPU) if it had wifi and not the ethernet … Doh!
> The allwinner runs too hot for my needs
Huh?
45°C is too much, I have a ambient temperature sensor in the same board, and the cpu heat changes the value. And I would a cpu with less heat generation.
If you have wifi and a bunch of DC-DC supplies in a small space it’s going to heat up even if the processor isn’t getting that hot.
> 45°C is too much
What is this number based on? There were some thermal issues with 1st batch of NanoPi NEO (not Air) due to inefficient voltage regulators and some issues with a later Orange Pi Zero batch but other than that Allwinner H2+ and H3 at least with reasonable DVFS settings are not known to overheat. Also it’s rather easy to let the SoC remain at the lower Vcore voltage (1.1V with those cheap Allwinner thingies) by limiting maximum cpufreq to 912MHz or 816MHz.
Yea i’ve tried that, but i’ms till facing those issues with also A33 and a proper PMIC (Not the dummy dc-dc converter)
Even if the cpu is at 700mhz it is still too hot. heating the whole 10cm x 10cm PCB (Not the precise value but quite similar)
I don’t have space for a meta hetsink so its heat generation is a huge problem for me.
I think the issue you’re going to always have is that you have mutually exclusive criteria.
You can get something based on the i.mx6ull that will run cooler than most of the octo-core-mega-power TV box SoC based stuff but it’s not going to be cheap.
> facing those issues with also A33 and a proper PMIC
Well, PMICs emit heat on their own (on all my A20 boxes the PMIC temperature can also be read out via I2C) so really curious whether an RK3308 is an improvement. When board consumption correlates with emitted heat in any way then personally I’ve not dealt with something better than small H2+/H3 boards so far (leaving RPi Zero aside).
With pmic you have better voltages control than a simple DC dc with a voltage divider.
I know thap PMIC create heat, but in my case the SC was quite hot.
Drastic measures copper cooling pads on PCB and or turn individual cores on and off in CPU. If not needed nil GPU. Have you tried those?
Will rockchip consider open-source the DDR initialization code for this SoC?
If they do it, I will be very interested in this board 😉
Will check with Rockchip about that. It should not be a problem.
What about RK3308G which has integrated DDR ?
anyone know how to get this affordably in europe?
official european rockpi resellers charge double the price! (and 6 times the price for the acryl case…)
Please, can anyone tell is the “rock pi” would support for “raspbian Os” ?
hi all
how to access GPIO in rock pi S bord
and also give me libmraa-rockpis proper link
If you goto the Tchip Store on Aliexpress and then under products select Embedded, there are two Mini PC, base on variants of the RK3308 chip.