Tag Archive: cubieboard


Let’s go straight on to installing ArchLinuxARM on the CubieBoard. Currently I am using my phone’s 8 GB µSD card. I have bought a new 16 GB µSD card for use with the CubieBoard, so I can put the 8GB one back into my phone, and be able to listen some music while being away from home.

Creating a bootable media is straight forwards. There is a script that does all the work. The boot process is similar as I have described for the BeagleBoard, there is a pre-boot loader (sunxi-spl.bin) which loads the boot loader (u-boot.bin).

Let’s begin, shall we?
Download https://raw.github.com/linux-sunxi/sunxi-bsp/master/scripts/sunxi-media-create.sh
Download http://dl.linux-sunxi.org/amery/sunxi-3.0/latest/cubieboard_hwpack.tar.xz
Download http://archlinuxarm.org/os/ArchLinuxARM-sun4i-latest.tar.gz

As with the BeagleBoard guide, I am linking to the latest versions above. Things might change. This guide is based on the versions stated below:
http://os.archlinuxarm.org/os/sun4i/ArchLinuxARM-2012.08-sun4i-roofs.tar.gz
http://dl.linux-sunxi.org/amery/sunxi-3.0/20130114-2310/cubieboard_hwpack.tar.xz

Please note: the script required sudo to be installed. I am not fond of sudo, and usually don’t have it installed. I don’t like the idea my user password grating root rights. I prefer that root rights require a different password, therefore I use su to gain root rights on my systems. So, don’t forget to install sudo if you don’t have it, or modify the script.

Update: On a CubieForums thread, someone had a problem with the script and suggests a patch. For me the script worked fine, but if you’re having problems with the script, take a look at this post

[andre@hplaptop cubieboard]$ ./sunxi-media-create.sh /dev/mmcblk0 cubieboard_hwpack.tar.xz ArchLinuxARM-sun4i-latest.tar.gz 

===
=== Partitioning /dev/mmcblk0 ===
===
[sudo] password for andre: 
1+0 records gelezen
1+0 records geschreven
1048576 bytes (1,0 MB) gekopieerd, 0,206529 s, 5,1 MB/s
Even controleren of iemand deze schijf nu gebruikt...
OK

Schijf /dev/mmcblk0: 476416 cilinders, 4 koppen, 16 sectoren/spoor
sfdisk: /dev/mmcblk0: onbekend partitietabeltype

Oude situatie:
sfdisk: Geen partities gevonden.

Nieuwe situatie:
Eenheden: sectoren van 512 bytes, tellend vanaf 0

 Apparaat Opst    Begin     Einde  #sectoren  ID  Systeem
/dev/mmcblk0p1          2048    133119     131072   c  W95 FAT32 (LBA)
/dev/mmcblk0p2        133120  30490623   30357504  83  Linux
/dev/mmcblk0p3             0         -          0   0  leeg
/dev/mmcblk0p4             0         -          0   0  leeg
Waarschuwing: er is geen primaire partitie gemarkeerd als opstartbaar.
Voor LILO maakt dit niets uit, maar DOS MBR zal niet van deze schijf opstarten.
De nieuwe partitietabel is met succes weggeschreven.

Herinlezen van partitietabel...

Als u een DOS-partitie gemaakt of gewijzigd hebt, bijvoorbeeld /dev/foo7,
gebruik dan dd(1) om de eerste 512 bytes nul te maken:
  dd if=/dev/zero of=/dev/foo7 bs=512 count=1  (zie man fdisk(8))

===
=== Format Partition 1 to VFAT ===
===
mkfs.vfat 3.0.13 (30 Jun 2012)

===
=== Format Partition 2 to EXT4 ===
===
mke2fs 1.42.6 (21-Sep-2012)
Verwerpen van blokken: voltooid                        
Bestandssysteemlabel=
Soort besturingssysteem: Linux
Blokgrootte=4096 (log=2)
Fragmentgrootte=4096 (log=2)
'stride'=0 blokken, 'stripe'-breedte=0 blokken
950272 inodes, 3794688 blokken
189734 blokken (5.00%) gereserveerd voor systeembeheer
Eerste gegevensblok=0
Maximum aantal bestandssysteemblokken=3888119808
116 blokgroepen
32768 blokken per groep, 32768 fragmenten per groep
8192 inodes per groep
Superblokreservekopieën opgeslagen in blokken: 
	32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208

Reserveren van groepstabellen: voltooid                        
Schrijven van inodetabellen: voltooid                        
Aanmaken van journal (32768 blokken): voltooid
Schrijven van superblokken en bestandssysteem-metagegevens: voltooid


===
=== Extracting HW Pack ===
===

===
=== Extracting RootFS ===
===

===
=== Copy U-Boot/SPL to SD Card ===
===
20+0 records gelezen
20+0 records geschreven
20480 bytes (20 kB) gekopieerd, 0,0171501 s, 1,2 MB/s
169+1 records gelezen
169+1 records geschreven
173412 bytes (173 kB) gekopieerd, 0,0428142 s, 4,1 MB/s
Copy VFAT partition files to SD Card

===
=== Copy rootfs partition files to SD Card ===
===
Standard rootfs

===
=== Copy hwpack rootfs files ===
===
Done.

We are using a hwpack from linux-sunxi.org. Linux-sunxi.org works on Linux support for Allwinner SoCs. This is still under active development. Therefore we aren’t using an Arch kernel. The Arch kernel fon sunxi just panics when trying to boot it on the CubieBoard. The script installs the kernel and kernel modules on the µSD card. I don’t really like the idea of having files in my file system the package manager isn’t aware of. I might have a look at creating a package for those files.

Anyhow, there are differences between various Linux distros. The µSD card as produced by the script won’t work completely for ArchLinux. Now, the sudo-using script is done, give me real root, and let’s rock on! In the hwpack, there is a file /etc/modules, in which modules to be loaded at boot time are listed. However, on ArchLinux, modules to be loaded during boot are stored at /etc/modules-load.d/*.conf. Therefore we execure the following commands:

[root@hplaptop cubieboard]# mount /dev/mmcblk0p2 /mnt/b
[root@hplaptop cubieboard]# cd /mnt/b/etc
[root@hplaptop etc]# mv modules modules-load.d/cubieboard.conf

Apart from the way to specify the modules to be loaded during boot, another difference is the location of modules. The hwpack still uses, what ArchLinux used to do, /lib/modules, however, nowadays the location should be /usr/lib/modules

[root@hplaptop etc]# cd /mnt/b/lib/modules/
[root@hplaptop modules]# mv * /mnt/b/usr/lib/modules
[root@hplaptop modules]# cd ..
[root@hplaptop lib]# rmdir modules

Update: Also, the other libraries will have to be moved to /usr/lib, otherwise the system will not be able to upgrade afterwards. This is what happens when you put files in your file system the package manager is not aware of. I need to package those files!

Update: The libraries seem to be available in an AUR package mali400, therefore they may be removed at this stage and installed later. Just to be safe, keep a copy of them. Also note, to compile xf86-video-mali you need the headers for libump, which is not in the mentioned mali400 package. I am still investigating this, but I should write about X configuration soon. However, I got a lot of things I am working on. As always, no promises.

[root@hplaptop b]# mv lib/framebuffer/ usr/lib/
[root@hplaptop b]# mv lib/x11 usr/lib/
[root@hplaptop b]# mv lib/libvecore.so usr/lib/
[root@hplaptop b]# mv lib/libMali.so usr/lib
[root@hplaptop b]# mv lib/libUMP.so usr/lib

In theory, we’re ready to boot now. However, there are a few more adjustment I would like to make before actually booting. One of the things about the CubieBoard is, it doesn’t have a MAC address burned in its EEPROM. Therefore it will have a random MAC address every time it boots. This is undesirable, therefore I will have to fix a MAC address. As explained on http://linux-sunxi.org/EMAC, we can configure the MAC address in the the script.bin file, a configuration file that holds information about the board. In order to manipulate the files, we need the tools bin2fex and fex2bin. We can find those tools in the AUR repository, package sunxi-tools-git.

The fex file is a human-readable version of the configuration file. First we decode the binary configuration file to a fex file, and we create backups of both the binary and text versions.


[root@hplaptop ~]# mount /dev/mmcblk0p1 /mnt/a
[root@hplaptop ~]# cd /mnt/a
[root@hplaptop a]# cp script.bin script.bin.bak
[root@hplaptop a]# bin2fex script.bin script.fex
fexc-bin: script.bin: version: 0.1.2
fexc-bin: script.bin: size: 43216 (76 sections)
[root@hplaptop a]# cp script.fex script.fex.bak

Now, I will edit the script.fex file and add a MAC address. I am using one of the MAC addresses it dynamically configured before I was using my own script.bin file. PLEASE NOTE: DO NOT USE MAC ADDRESS BELOW! MAC ADDRESSES ARE SUPPOSED TO BE UNIQUE


[dynamic]
MAC = "8a413f5bf892"

Convert the fex file back to its binary equivalent:


[root@hplaptop a]# vim script.fex
[root@hplaptop a]# fex2bin script.fex script.bin

So far so good, now we’ve fixed the MAC address, I can configure my “DHCP server” (inside the Fritz!BOX) to give it a static IP address, so I can always SSH into the box from my LAN. It’s really annoying when you never know what IP address the box will have.

But, I would also like to connect a monitor to my CubieBoard. What I wrote about this last December is already outdated. Like I said, the Linux kernel for this board is under active development, and stuff that didn’t work yet in December, may work in January. Back in December I wrote, configuration of the resolution goes through the script.bin file, which I’ve just mentioned. However, according to the fex guide, in hdmi mode, I can only specify “tv” resolutions, but my monitor got 1280×1024. The current kernel however, is able to parse the EDID and select the correct resolution, just like the Raspberry Pi does. However, on the CubieBoard it didn’t work quite well. I will investigate this later, but for now, another new feature is the possibility to specify a resolution as a kernel parameter. This is what I am using now to boot up my CubieBoard. The parameters are explained on a Google Groups post about a Fedora release for Allwinner based devices.

According to the parameters explained in that post, I would need to use disp.screen0_output_type=3 disp.screen0_output_mode=1280x1024p60
Put the following in uEnv.txt on the FAT partition


boot_mmc=fatload mmc 0 0x43000000 ${fexfile}; fatload mmc 0 0x48000000 ${kernel}; bootm 0x48000000
extraargs=rootwait disp.screen0_output_type=3 disp.screen0_output_mode=1280x1024p60
fexfile=script.bin

Well… I suppose this is it for now. I am not discussing configuration of the system for the BeagleBoard and CubieBoard now. That’s not board specific, and I have thoroughly discussed this for my Raspberry Pi. A thing I might be discussing in the future is how to configure hardware video acceleration for both BeagleBoard and CubieBoard. However, I will have to investigate this first, so no promises.

Regarding the hdmi/dvi output: It is not working perfectly, as I have to specify the resolution as a kernel parameter. Moreover, when my monitor is directly connected over a hdmi->dvi cable, the monitor complains I should configure a resolution of 1280×1024@60Hz. It thinks I am giving it 1282×1026@60Hz. So, in both directions two pixels too much, and it displays those as a row/column of purple pixels at the left and bottom of the screen. However, when I use my HDMI->VGA adaptor, the screen happily accept the signal as 1280×1024@60Hz.

I will investigate the display issues later, including what the kernel thinks about my EDID. I will also look at how it behaves with the HDMI->VGA adaptor without extra resolution hints in the uEnv.txt, and also connect a CRT monitor, as those are usually a little more flexible in supported frequencies.

The fact I have a working output at the desired resolution now makes my project to hook up a VGA connector to the CubieBoard get a lower priority. However, I intend to still investigate this, as this information is of interest to the CubieBoard community. Besides, yesterday I found the 2mm dupoint cables in my mailbox, so I am finally able to connect something to the CubieBoard I/O pins. Well… that’s a disadvantage of the CubieBoard. All I/O pins are 2mm, for which the cables are not so common.

Edit: One more after-boot comment
After upgrading packages ( # pacman -Syu ) open the uEnv.txt file on the FAT partition and add init=/usr/lib/systemd/systemd to enable systemd, otherwise you will still be using the old rc.conf initscripts.

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.

DSC_0002

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)