Lots to get to, so I’ll just jump right in:
I gave up on this device a bit too soon it seems. Someone found these blog posts and reached out about rooting a CX-R8. While I wasn’t able to help him much, he helped me greatly by providing links to a TWRP recovery image which makes it super simple to install a SuperSU update.zip file to the system allowing root access. Very cool. I’ve linked the images to my files page (available at the link above). Downloading it this way is a lot easier than the forums and EXE wrapped downloaders I found.
That’s about all I have for the CX-R8. I have mine in use as a media player at a friend’s house with Android at this point because the bootloader was such a pain in the butt to use.
No major updates here either. I’ve also been using this as a media player locally, but since retired it because it’s having all sorts of stuttering problems even with just MP3 playback through Kodi. I’m betting it’s got something to do with the 3 billion plugins they install at the factory for me. Haven’t cleared it out yet to see if that helps.
Supposedly shipped months ago. I’ve not seen it, never got a tracking number (shipping notification, but no tracking) and the seller is not responding to email. So much for that $200.
I was pretty excited about this, and have it partially working. The major problem is the Android kernel is TERRIBLE for everything except Android and piece of hardware seems to ship with it. Some but not all of the drivers for the RK3368 are in the mainline 4.4 kernel, maybe enough to do what I want (ethernet and serial console, don’t care about video at all) but I’m not sure. The other issue is the U-boot image everyone ships with is garbage as well, supporting only the Android kernel format of a signed image written directly to a mmc partition. The good news is that unlike all the other RK3368 boards and images I have found so far, the Geekbox folks post EVERYTHING to Github. So, I’m going to try and forward port the U-boot code for the RK3368 to the current mainline and see what happens. Then I might be able to use the PXELINUX/EXTLINUX/ISOLINUX style config file to move between kernels which would be a complete joy. For now, I’m trying to build Chef images in a chroot just to get something out the door. To make matters worse, I bought two geekbox systems in order to build on one while hacking around with the other. Having only a single CX-R8 taught me that having a single box you can login to is non-delightful. Well, the second geekbox was the victim of an unfortunate static discharge accident and is now toast. So I’m waiting for a replacement to ship from China, and hoping this one won’t take two months to arrive.
I’m happy to report that I have finally achieved what I wanted to build on an ARM board. It took a lot of work but the TK1 is finally doing what I want: a Linux 4.4 kernel on Debian 8 armhf providing LXC containers for various distros to build and test on. Getting here was hard. Like every other board, this too ships with an Android configuration highly modified 3.10 kernel and an ancient U-boot. Building a new kernel worked, but it would not boot. Folks on the #tegra IRC channel suggested upgrading U-boot. Again, only have the single TK1 (assumed the Cubieboard would have arrived by now) and was compiling on the TK1 for the TK1 (which avoided cross-compiles but was not smart).
I thought U-boot was hard to screw up, and I was very wrong. The biggest issue was the upstream code has a single configuration entry that is incompatible with the default kernel: the length of the command line is limited to 512B and the default command line is well longer than that. I wound up running around looking at definitions of CONFIG_SYS_CBSIZE and finally found you had to change one in particular to solve the problem:
diff --git a/include/configs/tegra-common.h b/include/configs/tegra-common.h index ba819c4..b448b4b 100644 --- a/include/configs/tegra-common.h +++ b/include/configs/tegra-common.h @@ -76,7 +76,7 @@ * Increasing the size of the IO buffer as default nfsargs size is more * than 256 and so it is not possible to edit it */ -#define CONFIG_SYS_CBSIZE (256 * 2) /* Console I/O Buffer Size */ +#define CONFIG_SYS_CBSIZE (256 * 4) /* Console I/O Buffer Size */ /* Print Buffer Size */ #define CONFIG_SYS_PBSIZE (CONFIG_SYS_CBSIZE + \ sizeof(CONFIG_SYS_PROMPT) + 16)
After that, it was much easier. Having a command line of 1024 bytes meant the stock L4T install would boot and I could debug correctly. I also didn’t realize that LXC required about 20 kernel configuration options, but was able to get that all straighted out. I’ll post my kernel config, U-boot config, kernel package, and extlinux.conf in a few days. With that all configured, that box is humming along pretty well. Booting off of SATA is strage with the Patriot BLAZE SSD I have installed, it takes about 20sec of SATA errors on boot and then works just fine. Not sure if that is a Tegra bug, SSD bug, Kernel bug, or what. The 3.10 kernel exhibited the same behavior. I’ve been able to build Chef clients for Debian 7 and 8 for the armhf and armel architectures. Next is to add Ubuntu 14.04 ARMv7 support, and then wrap it all up in a CI pipeline.
More to come
That’s about it for now. The TK1 is not responding to SSH and the RPi I was going to use as a term server for it is segfaulting all over the place. I guess I’ll replace that with a RPi2 shortly to make that issue go away. Once I can get back into the base OS, I’ll post all of the packages and configs for general consumption. I still don’t have PXE booting working with my U-boot but it’s not the end of the world. USB, SATA, and MMC all work so there are options. On top of all of that GitHub is down at the moment, so I can’t do much until that comes back up. I’m at PAX South this weekend, but expect to post another update during next week sometime.