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:
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:
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:
The front of the box:
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:
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.
Here we are, with heatsink installed (somewhat satisfying engaging those heatsink clips), case fan plugged in, and serial cable attached:
I plugged the fan into pins 4 (5v DC, red lead) and 6 (DC ground, black lead), according to this pi3b GPIO pin diagram:
It came with a USB to serial cable, apparently of the following specs:
Chasing down information on ADAFRUIT's site, I found a short tutorial:
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:
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).
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.
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:
I'm not shooting for this as my first run, but should I want to, there are some useful instructions here:
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.
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.
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)
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
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:
Furthermore, according to this page:
I see the following nugget:
… 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…
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 boot
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.
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.
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.
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.