Tag Archives: x5mini

linux mainline: minix neo x5 mini: USB works!

yay, progress. (by other people in the mainline community, I’m just enabling sections in devicetree files and building and testing.)

So, if you’ve built a kernel, and you think it should work, but you’re getting errors in syslog that look like this…

Jan  1 00:00:28 linaro-developer kernel: usb 2-1: new full-speed USB device number 3 using dwc2
usb 2-1: device v1a86 p7523 is not supported
usb usb2-port1: unable to enumerate USB device
Jan  1 00:00:29 linaro-developer kernel: usb 2-1: device v1a86 p7523 is not supported
Jan  1 00:00:29 linaro-developer kernel: usb usb2-port1: unable to enumerate USB device
Jan  1 00:00:59 linaro-developer kernel: usb 2-1: new high-speed USB device number 4 using dwc2
usb 2-1: device v0fce p5171 is not supported
usb usb2-port1: unable to enumerate USB device
Jan  1 00:01:52 linaro-developer kernel: usb 2-1: Dual-Role OTG device on HNP port
Jan  1 00:01:52 linaro-developer kernel: usb 2-1: device v0fce p5171 is not supported
Jan  1 00:01:52 linaro-developer kernel: usb usb2-port1: unable to enumerate USB device

This is actually a problem with your USB OTG config. Make sure that both CONFIG_USB_OTG_WHITELIST and CONFIG_USB_OTG_FSM are not set

A quick rebuild and reflash and presto…

Jan  1 00:00:32 linaro-developer kernel: usb 2-1: new full-speed USB device number 2 using dwc2
usb 2-1: device v1a86 p7523 is not supported
Jan  1 00:00:32 linaro-developer kernel: usb 2-1: device v1a86 p7523 is not supported
Jan  1 00:00:32 linaro-developer kernel: ch341 2-1:1.0: ch341-uart converter detected
Jan  1 00:00:32 linaro-developer kernel: usb 2-1: ch341-uart converter now attached to ttyUSB0

It’s still “not supported”, but I’m led to believe that means it’s not supported as a gadget in some manner.

The only additions to the device tree for the minix board were…

&usb_host {
       status = "okay";

&usb_otg {
       status = "okay";

Unfortunately, “only” these additions means there’s no power control for vbus. So the usb devices only work on the second port, if you have the funky A-A recovery cable plugged into the dual mode OTG/Host port used for recovery. Working out more pins is an ongoing project.
Thanks as always to the kindly people of #linux-rockchip

Further linux mainline adventures on minix neo x5 mini

This is a follor on from the last post, and as before, is a bit of a braindump post.

So, basically, it’s working now. The mystery part was adding “rootwait” to the kernel command line, presumably because of the mmc controller not having finished finding the card before it tried to mount root. This was only the kernel command line in the _linux_ build, nothing to do with the rockchip parameters file at all.

I followed the directions at http://hwswbits.blogspot.com/2013/11/your-own-official-linux-distro-in-sd.html to make an SD card with just the linux RFS. I’m still working on a generally “simpler is better” process. No initramfs, modules built in, plain RFS on sdcard because nand doesn’t work in mainline linux.


wget http://releases.linaro.org/14.08/ubuntu/trusty-images/server/linaro-trusty-server-20140821-681.tar.gz # or similar
sudo umount -l /dev/sdd
sudo mkfs.ext4 -F -L linuxroot /dev/sdd
sudo su - # to keep permissions
cd /run/media/karlp/linuxroot
tar -xf ~karlp/Downloads/linaro-trusty-server-20140821-681.tar.gz --strip 1
# back to regular user

Then put the sdcard in the minix and power cycle, and yay, I finally have a semblance of a linux system booting up!

It’s not entirely complete, but it’s getting a lot further than before!


I still don’t have any of the following working yet…. so it’s still a ways to go

  • ethernet
  • wifi
  • usb


linux-rockchip v3.17-next on minix neo x5 mini

This is a braindump post, probably of very little interest to anyone but myself. It outlines further adventures towards getting a plain linux system booted on a minix neo x5 mini.

rk3066 support is expanding in the bleeding edge linux trees, and seeing as I don’t care about HDMI (yet) for my purposes, I thought it would be a good way to go forward. Device tree support, recent, near vanilla code, a snowflakes chance of getting a patch to work, and a single clear path to upstream. Of course, I thought for practice, I should start with one of the existing “gpl release” trees, all built on 3.0.x. That was an adventure. I tried the “omegamoon” repository, which _seemed_ to be the most uptodate, with backports of “important” things. https://github.com/omegamoon/Rockchip-GPL-Kernel

We ignore all the build script crap, at least until we’ve looked at them all, because we’re trying to work out what they’re doing, not just monkeys on keyboards.

$ export ARCH=arm
# This line your toolchain, mine is from "yum install gcc-arm-linux-gnu" on fedora 20
# Note, that you can actually skip this with the right entries in your .config
$ export CROSS_COMPILE=arm-linux-gnu-

In any tree, have a look in arch/arm/configs for an appropriate defconfig for your device…. (This is where it gets fun!)
So, let’s start with something basic

make rk3066b_sdk_defconfig
# now we would need to go into menuconfig and make sure we've turned on drivers we might need....
# but let's just build this one first and see what we get....
make -j8

And… it fails here. Awesome. Turns out all the 3066 configs here don’t even compile, presumably because of rk3188 support getting patched in, without any testing. so, toss this repo out and try another…

We’re going back to a “clean” rk3066 tree, following the directions here: http://hwswbits.blogspot.com/2013/11/linux-on-ug008-tv-box-rk3066.html This site has been generally helpful, and the ug008 is a very similar device to the minix neo x5 mini. I originally intended to go all the way back to basics, just follow any build guide first, make sure the code worked as is, before I tried anything more specific to the x5mini.

git clone https://github.com/Galland/rk3x_kernel_3.0.36 galland-rk
cd galland-rk
cp galland.config .config
make menuconfig
General Setup->Cross Compiler tool prefix -> Update the prefix so you don't have to export CROSS_COMPILE...

watch it fail…

/home/karlp/projects/galland-rk3x-3.0.36/scripts/gen_initramfs_list.sh: Cannot open '../initramfs/initramfs.cpio'

Ok, that was clearly skipping steps. Why do I need a damn initramfs, I just want to build in the modules I need in one go! But, ok, we’re going to follow the instructions given.

clone galland initramfs image, choose to use the one with rk mtd nand support, as we are hoping eventually to get linux, not android. rebuild
watch it fail, no uudecode. wtf?! and yum search uudecode only turns up a perl module?! Turns out you need the sharutils package. Ok, my bad, this was listed at the top of galland’s page of requirements. No idea why I haven’t had this installed already before, but so be it, install and make again…

Realise it doesn’t compile either. Bugs in the drivers/mtk_wcn_combo/drv_wlan/wlan/common/wlan_lib.c file. Awesome. I did consider resetting this repository to the date the blog post was written, and also looked at the rest of the forks, but ultimately decided, I wasn’t interested in trying this any further, they were all deadends. On to “near” mainline.

from #linux-rockchip on freenode, on earlier discussions I’d come across a more recent repo, on kernel.org no less, from one of the people who’s involved in mainlining efforts for rockchip support.

So, this is now…. _very recent_
Git repo: git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git
Branch: v3.17-next/rk3xxx-dts

I’ve hacked a .config together, but I don’t know if it’s worth sharing at this point. So many options!

make -j8
# That spat out arch/arm/boot/zImage
make scripts # This makes the dts/dtb compiler
make rk3066a-bqcurie2.dtb # The only rk3066 in the tree, this is where I'll eventually have to make one for the minix neox5 mini
# that spat out arch/arm/boot/rk3066a-bqcurie2.dtb
cat arch/arm/boot/zImage arch/arm/boot/rk3066a-bqcurie2.dtb > zImage_with_dtb
[rktools]/rkcrc -k zImage_with_dtb > kernel.img
rkflashtool w kernel kernel.img (Or flashkit, or whatever)

Yay, now we actually get a booting kernel that we built ourselves….

425482 Starting kernel...@0x60408000

Uncompressing Linux... done, booting the kernel.
Booting Linux on physical CPU 0x0
Linux version 3.16.0-rc3 (karlp@teros) (gcc version 4.8.2 20140120 (Red Hat 4.8.2-2) (GCC) ) #1 SMP Wed Jul 30 21:08:48 GMT 2014
CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7), cr=10c53c7d
CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
Machine model: bq Curie 2
..... snip....
Please append a correct "root=" boot option; here are the available partitions:
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
CPU: 1 PID: 1 Comm: swapper/0 Not tainted 3.16.0-rc3 #1
..... snip (same on cpu2) ....

whee, that’s actually doing the right thing. It actually gets all the way to failing to mount a rootfs, which is reasonable, as I hadn’t configured one, mounted one, or set anything up on an sd card. So, I guess next, we’re looking at making at least a stub rootfs, and looking at maybe a more specific device tree file for this hardware.

Note: If you don’t concat the DTS to the end of zImage, you’ll get a boot something like this…

 424337 Starting kernel...@0x60408000

Uncompressing Linux... done, booting the kernel.

Error: unrecognized/unsupported machine ID (r1 = 0x00000bfa).

Available machine support:

ID (hex)	NAME
ffffffff	Generic DT based system
ffffffff	Rockchip Cortex-A9 (Device Tree)

Please check your kernel config and/or bootloader.

A good write up of this is at http://billauer.co.il/blog/2014/02/uboot-linux-dtb-fdt-device-tree/

minix neo x5 mini – backup partitions and investigate

Urgh, I hate the massive pile of rom noise around anything to do with android devices.

I’m using https://github.com/neo-technologies/rkflashtool because it appears to be actually maintained. https://github.com/linuxerwang/rkflashkit is also somewhat convenient, though it’s gui only. If it was a nice python tool with a gui front end that would be even better. (no idea why you need waf and install either, simple “python run.py” is perfectly suitable.) libusb+python is perfectly acceptable for this sort of thing. No idea why people went straight to C code. https://github.com/neo-technologies/rockchip-mkbootimg looks good too, but I’ve not poked it yet. Anything that’s being maintained basically.

A commonly referred tool, https://github.com/naobsd/rkutils while often pointed to, is effectively a dead end with zero follow up commits. I’ve no interest in following that nest of forks.

Anyway, here’s the bits that actually worked to open up the boot partition image extracted with either rkflashkit or rkflashtools…

  • ./rkflashtool r boot > boot.img
  • dd if=boot.img of=bootimg.gz skip=8 bs=1 count=20000000
  • mkdir hohoho && cd hohoho
  • gunzip < ../bootimg.gz | cpio -i --make-directories

According to this review of boot.img formats, this means the x5mini uses format 4.

karlp@teros:~/projects/rkflashtool/hoho (master)$ ls
charger       init.goldfish.rc       init.usb.rc               sbin                 ueventd.rk30board.rc
data          init.rc                proc                      sys
default.prop  init.rk30board.rc      res                       system
dev           init.rk30board.usb.rc  rk30xxnand_ko.ko.3.0.36+  ueventd.goldfish.rc
init          init.trace.rc          rk30xxnand_ko.ko.3.0.8+   ueventd.rc
karlp@teros:~/projects/rkflashtool/hoho (master)$ 

Still learning the pieces, this is as much diary as blog.

Minix NEO X5 mini – teardown and serial console

Well, I bought a “Minix NEO X5 mini” for various experiments, eventually planning just a plain linux server, with ethernet and wifi, and a pile more ram and flash than the regular OpenWRT router platforms. I chose this based mostly on the smallest, cheapest that had a physical ethernet port. The other contender was the UG008. (And UG008B) Those are marginally smaller, and have one less fullsize USB, also, I _thought_ I’d read good instructions on getting linux running on the x5mini, but it turned out the instructions were for the x5 (full size) which is very similar, but not the same. I’ve since found instructions for the ug008, maybe I should have bought that. It also has a power button and from the pcb pics, looks like the pads for test points are bigger. No heatsink though, and I’d heard it’s wifi wasn’t as good. (Rumous and hearsay, I’ve no idea really) The second fullsize USB port however, is kinda of interesting. The x5mini came with a rather unusual fullsize USB A male-male cable. And there’s no microusb port for the OTG like normal. Plugging this in to a regular pc host would be disastrous, so the supplied android has a special menu option to enable “connecting to pc” which resets on every boot. If you do have it turned on, and you push the pinhole on the bottom while plugging in the power, you’ll get a usb device that ADB can find. dodgy, a regular OTG port would have been preferable.

So yeah, it works pretty well out of the box, but there’s enough reviews of that. We’re here to pull it apart. The little screws are glued in, so you need a good screwdriver, I almost stripped them getting them out. Then, whee, brown PCB! And whee, they put a weight in it to feel pro ;)

The wifi (rtl8188es) antenna is soldered on, then soldered to an adhesive antenna on the lid, a little awkward, but perfectly reasonable of course. Immediately on the board you can see two missing ICs, one, labelled “WIFI2” is almost certainly Bluetooth, which is not on the x5mini, but is on the x5. More curious though is missing QFP48 IC by the recovery button, and it’s 12 pin “STM_DEBUG” connector. It certainly reminds me of an STM32 footprint, though the debug for cortex-m is normally 10 or 20 pins, not 12? No idea. Two test points on this side, T23 and T24, if it’s indeed a bluetooth module, this is possibly a uart between them? *shrugs*

Back to the “top” side, ethernet is an SMSC LAN8720A, power is a TI T659102, which seems to be pretty common on these boards. There’s two filled jumper blocks with interesting text, “USB1 Device / USB1 Host” and “Auto power on enable/disable” but I’ll leave them for a later time. There’s a rather unexpected battery connector too. Minix doesn’t have any battery backed devices in their catalog, so someone’s design company has been working on this. So much for thinking that minix was an OEM.

T306 is RX, T307 is TX and T308 is GND, for a serial console at 115200, 8N1


Finally, here’s most of the bootup