Long overdue follow-up from my previous post. Let me dive in by topic:
After a lot of roadblocks, I’ve given up on this particular platform. The primary reason for this was getting the MK68 boxes and being able to compare the two. The CX-R8 is pretty hacker un-friendly. The bootloader does some form of signing the boot, recovery, and kernel images. All of the existing Rockchip tools I could find to make these images say the ones from the device have bad checksums, and the images it creates the device reports as having bad checksums. I wound up putting the stock image back on and giving this device to a friend as a media player.
Out of the box, this device is much more hacker friendly. To start with SuperSU is pre-installed in the factory image, so the device is pre-rooted. Very handy for getting files on and off. On the hardware front, there is some bad news. Looking at the top of the board there is a set of holes that look like the serial port on the CX-R8. Sadly, they are not. Looking at the “Top of board” image I posted, the port is on the far left hand side next to the processor heatsink. The pin on the left edge of the board is Ground, and the pin closest to the heatsink is +3.3v. The two in the middle? No idea, and I don’t have a scope to probe them properly. However, the UART2 serial port is shared with the SD card, so I was able to find that the RX pin is the 5th pad from the bottom and the TX pin is the 3rd pad from the top on this image. Also interesting: unlike the CX-R8, the OTG port is the USB port on the back of the device instead of the one next to the MicroSD slot. Also unlike the CX-R8, this is clearly stated in the manual (!!), and it came with a USB A-A cable for flashing (!!). The rkflashtool programs worked as expected, and I was able to put a stock Debian 8 initrd with no kernel modules in it, adjust the params file to my USB root filesystem, and watch it boot into Debian 8. I was able to make a USB drive with a arm64 root filesystem using the new debootstrap with qemu-static support. Very handy that.
However, now the bad news. Since I was using the kernel that ships with the device (in order to ensure the hardware is correctly supported) and that doesn’t have the correct hooks for f**king systemd. So, systemd fails to find the Ethernet device or the serial ports and thus no way to login to the device. I can think of two ways of working around this: build a new kernel or move off of systemd. Moving off of systemd on Debian 8 doesn’t look like an option, and Debian 7 didn’t ship with arm64 packages. There may be an arm64 Debian 7 repo around somewhere, but I haven’t found it yet (I also haven’t looked very hard). The second option is to build a new kernel. This leads to a couple of interesting issues. I haven’t found the RK3386 patched 3.10 kernel to just make some quick changes to the existing config, and it doesn’t look like they left the /proc/config.gz option on. The latest 4.3 kernel does look like it has enough support for the SoC and the Ethernet in order to get that all working, which is all I really need (no video is expected and that’s fine). However, building a kernel is not something I have done in a very long time and cross-compiling a kernel is something that I haven’t done in over a decade. Needless to say, that hasn’t gone anywhere very fast. Cross-compiling an arm64 kernel has been a complete disaster for me.
In brighter news: one of the nice folks in the #linux-rockchip channel (naobsd as I recall) pointed me at the GeekBox. It’s another RK3368 based system, but it comes with Ubuntu on it as a boot option and has a docking board with a SATA port! One of those, with the docking board, the UART adapter, and a real CPU heatsink with fan I was able to get for about $150. So I ordered two. They are currently very backordered, but the nice folks who will be shipping it to me from China assure me they will fulfill my order as soon as they are back in stock. I’m going to wait for one of those to show up, and build a new kernel on that for the MK68 and possibly just use that as-is with some containers or chroots on it for build targets on Debian 8 and Ubuntu. I’ll update again once those arrive for testing & compiling.
nVidia Jetson TK1
In the mean time, the Cubieboard 4 I ordered seems to be lost in the great black hole that is international shipping and customs without a tracking number. I was hoping to use this for all the ARMv6 and ARMv7 builds, but I’ve not seen it and the shipper is non-responsive to my inquires of a tracking or customs document number. Another kind soul on the #linux-rockchip channel suggested getting a Jetson TK1 board since it has a native SATA port (turns out very few ARM boards have native SATA, and that Geekbox docking board is just a SATA-USB interface as well). I figured this would be much easier to get something working with. So, I grabbed one via a Make: promotion for only $99. It arrived a few days ago.
This device comes running Ubuntu 14.04, which is very nice. The downside is that all the current gen ARM boards seem to target a heavily patched 3.10 kernel because that’s what Android requires. But, major MAJOR bonus: nVidia has found a great workaround for the bootloader issue that I’m going to steal for other boards that don’t implement this. They also use u-boot to bring up the board, but then embed EXTLINUX (from the SYSLINUX) project as a second stage bootloader. This means there is a text file on the system that tells it what kernel to use, and can even present a menu to choose what you want to boot from over the serial port. This is so much nicer than having to re-flash the parameters “file” from a host device while in recovery mode to adjust kernel command line options or try a new kernel!
With the Jetson having a SATA port and the Geekboards also having a SATA port I went and grabbed three 240GB SSDs from Fry’s post black friday for under $80/ea. The Patriot Blaze SSD I grabbed for the Tegra is giving lots of SCSI errors, but it also turns out that the board has an older software loadout on it’s internal flash. So, I went and got the latest build of their JetPack tool to install, and it’s been a parade of failures ever since.
The JetPack installer refuses to function on any host machine that is not x86_64 running Ubuntu 14.04. So, I put a LiveCD of 14.04 in a system with a 32GB ext4 formatted USB drive in to put the stupid installer on. It then goes and downloads a bunch of junk from the Internet, builds a new image, and slowly re-flashes all 16GB of flash on the TK1 over USB2. Then, it fails to boot. No idea why. The process is very unclear of what is supposed to happen, it may need to make a TFTP boot but while it can configure a DHCP server correctly, it’s not running it’s own TFTP server or putting the TFTP files in the right place, so I have no idea what it’s trying to do. I’m sure I’m missing some package it wants, but it’s not telling me that either. Grumble. Going to have to troll the nVidia developer forums next week to figure out what’s wrong with that. But soon, I hope I can get that working again and at least get the 32bit ARM build environments setup there.
So that’s where all the ARM stuff stands for now. Not a lot of successes to report, but some forward progress. More updates next weekend, I’m sure.