$9.9 ROCK Pi S is a Tiny SBC Powered by Rockchip RK3308 Processor

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 “ROCK Pi Summer Updates 2019” (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 RK3308 Board
Click to Enlarge

Rock Pi S board specifications:

  • SoC – Rockchip RK3308 quad-core Arm Cortex-A35 processor with built-in VAD (Voice Activity Detector)
  • System Memory – 256/512MB RAM
  • 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
Rock Pi S SBC
Click to Enlarge

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.

Support CNX Software - Donate via PayPal or become a Patron on Patreon

57
Leave a Reply

avatar
10 Comment threads
47 Thread replies
1 Followers
 
Most reacted comment
Hottest comment thread
26 Comment authors
RajkumarbernsteinsanderLaurentTom Cubie Recent comment authors
  Subscribe  
newest oldest most voted
Notify of
tkaiser
Guest
tkaiser

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…

Tom Cubie
Guest

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.

tkaiser
Guest
tkaiser

> 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?

Tom Cubie
Guest

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.

willy
Guest
willy

OK this can be a great solution then!

Jerry
Guest
Jerry

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.

tkaiser
Guest
tkaiser

> 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).

Jorgito Palotes
Guest
Jorgito Palotes

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.

tkaiser
Guest
tkaiser

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.

sander
Guest
sander

Talking about Armbian: do you know Armbian’s support plan for this ROCK PI S ? Not yet there on the Download page

willy
Guest
willy

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.

dgp
Guest
dgp

>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.

Jerry
Guest
Jerry

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.

dgp
Guest
dgp

>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.

Benjamin HENRION
Guest

“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…

dgp
Guest
dgp

>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.

eas
Guest

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.

eas
Guest

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!

Hans Ulli Kroll
Guest
Hans Ulli Kroll

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/

Rufik
Guest
Rufik

What about mainline kernel support for RK3308? Is it partially done at least?

tkaiser
Guest
tkaiser
JohnDoe
Guest
JohnDoe

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.

David Willmore
Guest
David Willmore

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.

dgp
Guest
dgp

>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.

David Willmore
Guest
David Willmore

I would love to see a similar SPI NAND interface/controller block become more common.

dgp
Guest
dgp

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

tkaiser
Guest
tkaiser

> If it’s meant for IoT then the RTL wifi is a show stopper

Curios: why exactly?

dgp
Guest
dgp

>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

Tom Cubie
Guest

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.

dgp
Guest
dgp

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.

Jon Smirl
Member

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.

TLS
Guest
TLS

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.

dgp
Guest
dgp

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.

TLS
Guest
TLS

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.

dgp
Guest
dgp

Those are supported in brcmfmac according to https://wikidevi.com/wiki/AMPAK

Ângelo Ferreira
Guest
Ângelo Ferreira

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”.

Wenting Zhang
Guest
Wenting Zhang

Wait a minute, RAM is only up to 1178Mbps? That slow? 1178MT/s sounds much more reasonable for DDR3

Member

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

Icenowy Zheng
Guest
Icenowy Zheng

Will rockchip consider open-source the DDR initialization code for this SoC?

If they do it, I will be very interested in this board 😉

Tom Cubie
Guest

Will check with Rockchip about that. It should not be a problem.

Laurent
Guest
Laurent

What about RK3308G which has integrated DDR ?

bernstein
Guest
bernstein

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…)

Rajkumar
Guest

Please, can anyone tell is the “rock pi” would support for “raspbian Os” ?