User Tools

Site Tools


Renegade ARM Computer with USB 3 / 4GB RAM


It always tends to start off the same way: a new weekend has arrived, the morning freshly unfolding. A few tasks to be done, and you start off with the best intentions of working on them, until you hear a loud “clink/thud” of a package being delivered.

“What could that be?” a thought lingers as you wander to the mailbox.

Upon opening it, an abundantly-taped package is found. Labels indicate shipping from overseas.

“Clearly something I ordered via some crowd-funding endeavor; but what?”

Removing all the tape, and getting ready to open, we are left with an innocent looking cardboard box:

A veritable treasure trove of distraction, inspiration, and discovery. Let's see what is inside…


Opening the box, we have at first glance:

Aha! THAT. I had completely forgotten about that. If memory serves it arrived ahead of schedule- they said it wouldn't be shipping until March. Huzzah!

Taking a closer look:

Renegade ARM Computer

The centerpiece of this endeavor, from the top:

From the side:

From the bottom:

…ohh, look at that: an eMMC socket tucked away on the bottom. That promises some decent I/O. Did this kit ship with one? Doesn't look like it. Drat.

I forget how I stumbled upon it. But once upon a time, and not all that long ago, this was an indieGOGO project:

Renegade IndieGOGO page

From the indiegogo page:

Renegade is our first board to feature DDR4 technology, USB 3.0 capability, and Gigabit Ethernet. This modern and powerful platform shares the same form factor as the Raspberry Pi 3 Model B* minus one USB port. It features both mainline Linux and Android 7.1 Nougat Support. Like all of our boards, it is designed completely with open-market components in collaboration with the Firefly team.

The regular site:

roc-rk3328-cc page at

The front of the box:

Specs Comparison

The aim of the renegade board is to be an all-around improvement to the raspberry pi 3. They even have a nice table of features comparing the two items:

As we can see, general spec boosts in processor speed, better chip design (28nM vs. the pi's 40nM), various hardware-accelerated crypto and video encoding/decoding functionality, faster memory, and the reasons I picked one up:

  • USB3: implies a faster underlying system I/O bus (in order to utilize USB3 speeds/bandwidth); the raspberry pi generally doesn't take much before you've saturated the bus, especially on I/O operations. If so, this should offer up some immediate perceived performance improvements over the pi (and not so much due to the improvements in processor and memory- make this same change on the raspberry pi and we'd likely notice similar boosts in performance. The raspberry pi, for all its wonders, is hobbled by some of the cheap parts that have gone into it).
  • gigabit ethernet: again, hinting at a better underlying system bus to handle the increased I/O demands of these resources.
  • eMMC: an unexpected surprise, also speaks towards better I/O. I'll have to pick up a module and take it for a spin.
  • 4GB RAM: I could actually care less that it is DDR4 RAM. My big thing is the amount. 1GB of RAM is certainly an improvement over the 512MB in the pi2B, but still- if you are wanting to do anything micro-desktop related, you hit limits very fast. And if you are doing anything resource intensive (say, clustering), having more memory on hand is ALWAYS helpful.
    • this also speaks to a long-standing desire of mine in my quest for ideal computing environments: I would LOVE to have an ARM computer as my main desktop. My computing needs aren't all that extensive (the LAIR pods are a case in point for this), and to have something non-Intel and still plenty capable, that's just where I want to be. And so many ARM boards tend to skimp on available memory. So I am excited to see what this board is capable of.

Getting things ready

This came with its own case (actually a pi3 compatible case, as it is peripheral and pin compatible), which included a case fan, along with a more sophisticated heatsink assembly.

things hooked up

Here we are, with heatsink installed (somewhat satisfying engaging those heatsink clips), case fan plugged in, and serial cable attached:

fan connection

I plugged the fan into pins 4 (5v DC, red lead) and 6 (DC ground, black lead), according to this pi3b GPIO pin diagram:

serial cable

It came with a USB to serial cable, apparently of the following specs:

  • PL2303TA chipset
  • USB to TTL Serial Cable
  • Pinout: Red 5V, Black 0V (Ground), White RX, Green TX

Chasing down information on ADAFRUIT's site, I found a short tutorial:

console cable on pi

As it turns out, the renegade board has RX1 and TX1 silkscreened next to the pins, which is also quite handy.

I connected it as follows:

  • pin 1 (DC 5v, red lead)
  • pin 9 (DC ground, black lead)
  • pin 8 (TX1, green lead)
  • pin 10 (RX1, white lead)

I've never thought to do serial communications on a raspberry pi before, so it'll be neat to see how well the distro works with it (I suspect just a raspy-config setting to enable console over serial, unless there's some other, JTAG-ish means of poking at lower level bits of a pi).

final assembly

Final assembly (somewhat less exciting, visually) is as follows:

microSD card slot

The pi2 had a nice spring-loaded insertion/ejection mechanism; the pi3 did away with it to cut costs.

This renegade board has the spring-loaded mechanism. Just enhances the experience.

Turns out they did not ship with a distro.. so I am downloading a version of Ubuntu 16.04 that has been prepared for this machine.

renegade pinouts

It seems this project was done in conjunction with the firefly people. Their site also has some useful information:

Not to mention a contextually-relevant pinout diagram:

Custom build a boot image

I'm not shooting for this as my first run, but should I want to, there are some useful instructions here:

Writing the boot image to the SD card

I think I've got some prebuilt files mentioned in the above link. I'm going to follow the tail-end instructions for writing things in their respective order.

Step 0: Identify the device

First critical step with any writing endeavor: figure out the device.

I'm on my Macbook as I do this, so instructions reflect that (namely, devices, which have a more BSD-flavor to them, and particular macOS tools for disk mounting/unmounting).

# diskutil list
/dev/disk3 (external, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:     FDisk_partition_scheme                        *15.9 GB    disk3
   1:             Windows_FAT_32 NO NAME                 15.9 GB    disk3s1

# diskutil unmountDisk disk3
Unmount of all volumes on disk3 was successful

So /dev/disk3 (and maybe /dev/rdisk3) are what I'm looking for.

Step 1: Boot files

Seems like we have to assemble the whole bootloader chain as well. This is something I've not really had the chance to do before:

# dd if=rk3328_loader_ddr786_v1.06.243.bin of=/dev/rdisk3 seek=0 conv=sync
316+1 records in
317+0 records out
162304 bytes transferred in 0.294588 secs (550953 bytes/sec)

We're basically writing a few different important bootfiles, at specific offsets:

# dd if=idbloader.img of=/dev/rdisk3 seek=64 conv=sync
168+1 records in
169+0 records out
86528 bytes transferred in 0.157344 secs (549928 bytes/sec)

I have heard of uboot before. A common bootloader on ARM devices:

# dd if=uboot.img of=/dev/rdisk3 seek=16384 conv=sync
8192+0 records in
8192+0 records out
4194304 bytes transferred in 7.450297 secs (562971 bytes/sec)

Whenever I see the word “trust” related to low-level computer operations, I shudder. ARM is great, but ARM has also been shackled with all this 'Digital Rights Management' and 'Trusted Computing' stuff. I guess if this board is intended to be an extensively open source one, I've got nothing to worry about… I still don't like the fact the hardware has been designed to require a trusted computing bytecode thing… adds an extra step of complication, needing to deal with cryptographically signed binary code and all. Do what you must:

# dd if=trust.img of=/dev/rdisk3 seek=24576 conv=sync
8192+0 records in
8192+0 records out
4194304 bytes transferred in 7.592834 secs (552403 bytes/sec)

Next something a little bigger than 8 or 16MiB:

# dd if=boot.img of=/dev/rdisk3 seek=32768 conv=sync
204800+0 records in
204800+0 records out
104857600 bytes transferred in 194.059517 secs (540337 bytes/sec)

Finally, the root filesystem:

# dd if=ROC-RK3328-CC_Ubuntu16.04_Arch64_20180124.img of=/dev/rdisk3 seek=262144 conv=sync
5359400+0 records in
5359400+0 records out
2744012800 bytes transferred in 5192.559726 secs (528451 bytes/sec)

UPDATE: all-in-one image

Turns out I either wrote one of the images wrong, or something wasn't as it should be, as my final result didn't result in any sort of functionality.

What DID work was when I wrote an all-in-one image (system.img) wholesale to the card:

# dd if=system.img of=/dev/sdb seek=0 conv=notrunc && sync

Setting boot device via serial

The directions seem to indicate some low-level firmware setting is needed to instruct the device to boot off the intended media.

It would appear there is a separate serial pinout for a low-level debug functionality; if you take a closer look at the Renegade GPIO pinout:

We see the following pins are identified for debugging:

  • 34 GND (black lead)
  • 36 TX2 (white lead)
  • 38 RX2 (green lead)

Furthermore, according to this page:

I see the following nugget:

  • The red lead should be connected to 5V if you want to power via the cable

… and that's exactly what I noticed happening when I first had it plugged in. It was fully able to power the device. That's a neat and good thing to know. For now, I have kept the red (power) lead unconnected.

I'm going to re-hook up the serial adaptor to these pins instead, and give serial access another try.

Okay, good to know:

Baudrate for the serial debugging is 1500000bps 8,N,1… that's pretty serious for a serial connection. And definitely not what I was using (which was 9600bps). Let's switch to that and see if we have lift-off…

Booting from SD card

According to the following page:

To set the device to boot from SD card, you must do the following at the prompt (as presented over the serial connection):

gpt write mmc 1 $partitions

Personally I'd love more information on this… I've caught mention that it is possible to boot off the eMMC card (would that be “mmc 2”??) And what's up with $partitions?? Clearly some syntax for a layer I'm not familiar with, and getting familiar with would unlock additional potential of this device.

Stability Fixes

First, it should be noted that some of these issues are likely caused by software (default 4.4.9x kernel that comes on the Ubuntu image). And that an updated kernel (especially a 4.15.x kernel) may well resolve some issues and mitigate the need for their workarounds.

Garbled Serial Console

Even after discovering the needed 1500000bps setting for the serial device, I was still getting significant distortions. Most numbers would seem to come through, but other text would remain unreadable. This required some creative debugging… I'd have to type a lot of things blindly to indirectly receive desired information.

But what seemed to resolve this entirely (and suddenly), was merely installing the eMMC module I obtained.

Hypothesis: Some on the indiegogo page were speaking of bent boards; I did not notice a bend, but what if there was one, and the act of putting in the eMMC and placing it in the case somehow put stress on things in the right way?

I could certainly test this by removing the eMMC and seeing if the garbledness returns. For now, it is merely an extra bonus. I don't plan on using the serial console so much now that it boots.

Freezing ssh sessions/poor local network behavior

Something I immediately noticed was that I could freeze up an ssh session by generating a lot of output. Running dmesg or even trying to edit any file in vi would lose me the session. Also, I was distinctly unable to transfer anything to or from the renegade board via scp with another machine on my network.

Yet, via apt-get I could pull down several megabytes of data without so much as a hiccup. So some issue manifesting locally on the network, that goes away when passing through a router/gateway? (Packet normalization?)

Various stackexchange forums spoke of verifying interface mtu (mine was fine, at the default 1500), or tweaking ssh settings (I don't see how it was applicable, given the remote works, yet local doesn't).

But there is a common underlying thread here: the ethernet interface.

The ethernet device (eth0) is a Realtek 8188 device.

[    2.390023] Realtek 8188EU USB WiFi driver (Powered by Rockchip,Ver 2.20.WFD) init.
haxx/projects/sbc/renegade.txt · Last modified: 2018/02/24 07:51 by wedge