Last friday, my CubieBoard arrived. I only had time today to play around with it. First of all, it turned out to be a 512 MB version. I was under the impression the CubieBoards from the Indiegogo campaign were the 1 GB version.
Anyhow, let’s get started. Since it is an Allwinner A10 based device, it *should* work as follows:
Prepare the SD card as for a Mele A100 and replace the script.bin file with the adequate version.
The script.bin file is a compiled fex file, using the fex2bin tool. It should be somewhere in that git repository as well, but there is an AUR package so just install sunxi-tools-git and there we go.
The package included an USB to 3.3 Volt serial cable. How to connect it however? A little looking around finds me the answer.
Connected to the serial console… nothing!!! Nothing at all.
Now…. I have been stupid. I had another USB-to-Serial adaptor inserted to my compyter, connected to an (unpowered) BeagleBoard. No wonder I saw nothing
on the serial connection!
So… connected to the correct serial port, I see an u-boot prompt, the usual countdown till boot. And booting the kernel. However…. the kernel isn’t very happy about the board…
The ArchLinux kernel is OOPSing… also, it detects 512 MB of RAM. This was supposed to be the 1 GB version of the CubieBoard, wasn’t it?
I have installed the script.bin for the 1 GB version. Perhaps that’s why it is having trouble? Replacing the script.bin file didn’t solve the issue.
I’ve downloaded a cubieboard specific boorloader/kernel from linux-sinxi which boots the board correctly. So, the board boots… however, using a kernel out of repository. I’m not that happy about having files in my filesystem pacman isn’t aware of.
Another issue with using this kernel is there are no kernel headers, so compiling kernel modules will be a problem as well.
So far so good, I’ve got a login prompt at the serial console. The system boots. Connecting the HDMI output to my DVI-D monitor doesn’t give me an output however. I will probably have to configure it somewhere. In the meantime, let’s look at some other stuff.
I’ve bought an HDMI -> VGA adaptor. Since my (second) Raspberry Pi is known to be working with my display, on it’s DVI-D input, I’ve decided to hook it up over VGA with the adaptor. This second Pi is not configured yet, just having (almost) unused image on it.
On boot, the monitor reports Out Of Range. This probably means the EDID information from the screen isn’t correctly passed through the HDMI interface, causing the Pi to select an unsupported resolution/refresh rate.
Of course it is possible to force a specific resolution in the config tile in the boot partition, but I consider this an ugly practice. So, software controlled resolution changing it is. It was a little work to figure this out, as it requires two separate tools to perform this action.
First there is fbset, a tool to configure the framebuffer. (Install package fbset)
Just setting
fbset -xres 1280 -yres 1024
doesn’t work. Therefore I have connected the monitor over DVI-D input again, and tried changing the resolution on a working screen. Even through the tool reports a different resolution, the content of the screen tells otherwise.
A little searching on the internet points me to a tool called tvservice. I have no idea to which package it belongs, it appears to be located in /opt/vc/bin. This directory is not in the path. It’s linked against libraries in /opt/vc/lib, which is also not in the library path. So, to tell ld to also look for libs there. (Note: temporary solution, also LD_LIBRARY_PATH was empty, otherwise I would have been replacing it with the command below)
export LD_LIBRARY_PATH=/opt/vc/lib
To list supported display modes
[root@alarmpi bin]# ./tvservice -m DMT
Group DMT has 8 modes:
mode 4: 640×480 @ 60Hz, progressive
mode 6: 640×480 @ 75Hz, progressive
mode 9: 800×600 @ 60Hz, progressive
mode 11: 800×600 @ 75Hz, progressive
mode 16: 1024×768 @ 60Hz, progressive
mode 18: 1024×768 @ 75Hz, progressive
mode 35: 1280×1024 @ 60Hz, progressive
mode 36: 1280×1024 @ 75Hz, progressive
To change resolution:
[root@alarmpi bin]# ./tvservice -e=”DMT 35″
This, indeed, does chnage the output resolution/refresh rate, however, it just outputs a blank screen. In order for it to work, afther changing the resolution with tvservice, the fbset command is required. Then it appears to work.
In the meantime, I have been thinking about other caused for this behaviour. I have heard about issues with similar adaptors in combination with the BeagleBoard. As the device is powered from the HDMI interface, it draws current from it. The current requirements were too high for the BeagleBoard, requiring a polyfuse to be replaced by a bigger one on the Beagle.
So, in order to test the device, I’ve hooked it up to the HDMI output of my laptop. The laptop (HP EliteBook 8530w) does not see the monitor connected. Not at all. At the moment when I unplugged the device, something funny happened.
Anyhow, seeing the results on the changing resolution on the Pi made me decide to give it another try. Surprisingly, this time it just worked out-of-the-box. I didn’t have to change any settings, the correct resolution was used right away.
I suspect the case was causing trouble again. There is this plastic case around my Pi, and the hole is just big enough for the metal part of the HDMI connector to pass through, however, the part where you hold the plug is against the cover, therefore, not allowing the plug go in as far as it normally would. This can cause some bad connection. Perhaps that’s what went wrong the first time. My usual HDMI->DVI-D cable has also bad contact issues, but it causes no signal.
This no-signal situation is what caused me to look into the online changing the output settings of the screen in the first place, as I don’t feel like rebooting until the damn plug makes contact.
However, I still have not verified the passing through of the EDID code. It could be that this tvservice is playing with me, and storing the resolution in the config file in the boot partition. It would not be neat if it did that, and I could just verify if the config file is untouched. Let’s assume for now, it just passed through the EDID as it should have.
Anyhow…. that was my Pi for today. I will have to look at the CubieBoard again, see how to make it generate some output on that screen. At least it boots, so it’s probably just a matter of configuration. And that’s going to be a little harder on the CubieBoard. The community is a lot smaller then the Raspberry Pi community, and AllWinner isn’t giving away much documentation about its SoC.
If it’s about documentation, a TI SoC is to be recommended I believe. I haven’t been reading much documentation myself, but that’s what I’ve been hearing. I still have that BeagleBoard C3 lying around. It’s that damn USB problem that’s keeping me from using it…. I should have returned it right away… I should… but back in the days I assumed it was a software issue and waited for a new kernel.
Well… the BeagleBoard, BeagleBoard-xM and BeagleBone are a little more expensive then Raspberry Pi and CubieBoard. I guess they’re also targeted at a different audience. Let’s just say, I’ve ordered a Raspberry Pi in the UK, I’ve ordered a CubieBoard in China, and a BeagleBoard in the USA. For the BeagleBoard I had to send a verification about the intended use to the American customs. Seriously!
P.S. Another funny observation: When unplugging the CubieBoard from its power source while connected to the supplied USB to serial cable, the power led remains lit (dimmed, but still emitting light)
