Tiny Devices

Although the TI CC debugger is a relative inexpensive debugging tool, I did stumble across a cheaper option that is compatible with the TI software suite (SmartRF Studio & IAR) and could be used for development or re-flashing a dead CC debugger/SmartRF04EB.

An alternative to the CC debugger is to use the more expensive SmartRF04EB development board. The SmartRF04 essentially contains a C8051F320 and along with additional circuitry for level shifting and on board peripherals. The chipcon debug/programming interface for these TI chips is just 3 wires Debug Data, Debug Clock and RESET. Therefore the interface required from the board is minimal if we disregard the level shifting feature and assume 3 volts.

So I started searching for a C8051F320 board that could possible could do the trick, in the end I found the understated EX-F320 development board by WaveShare. Initially I wasn't sure whether it would possible to use this board or not but ordered one considering its low cost (approx £12+£4p&p). Luckily I already had a Silabs programmer to flash the EX-F320, in fact the Silabs programmer also uses a C8051F320! Its possible to build a cheap Silabs parallel port programmer or buy a cheap clone from Aliexpress.

Just over a week later I received the EX-F320, it came with 2 different USB cables for powering the board, 2 sets of 2 pin jump leads and 2 sets of 4 pin jump leads (I can't see the point of the 4 pin leads, it would have been better to supply individual jump leads!).

A powering up the EX-F320 and verifying it was recognised by the Silabls programmer I downloaded and installed SmartRF Studio (SRFS). Next I flashed the bootloader (srf04eb_bootloader.hex) and the firmware (fw0400.hex) to the EX-F320. These files are located in \Program Files\Texas Instruments\SmartRF Tools\Firmware\SmartRF04EB. A quick restart of the EX-F320 would determined if the SmartRF04 firmware would run or not. Fortunately after power up the EX-F320 was recognised by SRFS as a SmartRF04 board.

The next step was to locate the SmartRF04 debug pins on the EX-F320, these turn out to be the following pins:

P0.6 - DD (DEBUG_DATA)

P0.7 - DC (DEBUG_CLK)

P2.3 (RESET)

Ideally the 3 pins should be protected with a buffer circuit (74HC245/74HC244) possible with the inclusion of pin P2.2 to enable ouput (have to verify with the SmartRF04 schematic). The EX-F320 also produces a regulated +3.3v supply which can be used to power the board to flash/debug.

Final stage was to test (I tested without a buffer circuit) chip detection. I used Ciseco XRF CC1110 module in combination with their Xino basic board.

The CC1110 was also detected by IAR (kickstart) and could be programmed/debugged without any problems.

Another plus point is that the EX-F320 can be used for 8051 development once it is no longer required for CC development.

This project came about because my existing alarm system an SL5 Friedland Response Alarm (Honeywell) system had no easy means to interface with it so that I could control it through sms or through the web. It then took off in a direction I wasn't expecting. My initial plan of attack was to interface through the phone port on the SL5 Control panel using an Linksys PAP2. Although I was successful in doing this the interface turned out to be rather clunky as it required a PAP2 plugged to the control panel along with an linux box (O2 Joggler) running asterisk.

So my next (crazy) idea was to see if I could somehow decode the RF protocol as this would allow me to possible talk to the Control panel or listen to the sensors. Having no experience of alarm systems technology didn't deter me nor the slim chances of dechipering the protocol.

After many months of hardware tracing, constantly staring at bit streams and analysing hex data the dectective work finally paid off. So here is the Nano SL5 alarm panel, possible the smallest alarm panel out there (although not as useful in its current state)! It actually consists of an XRF module reprogrammed with my custom software. This prototype consists of 2 LEDs, the Orange LED indicates the alarm is armed and the Red an alarm is trigged.

As you can see in my test setup I used a Friedland Wireless Keypad to arm/disarm the alarm and a PIR to trigger the alarm. First I have to Arm the alarm using the the Keypad which results in the Orange LED lit.

Next I triggered the PIR, this took some time as the PIR sleeps for 2 minutes between triggers caused by camera movement. This results in the Red LED lighting up to indicate alarm condition.

Finally we can disarm through the Keypad.

Hopefully this now opens up a number of opportunites as the alarm sensors can now be used for other applications. My initial idea is to develop the software so that all sensor information is provide through a serial port. It is also possible to mimic a sensor in order to talk to a real Control Panel. The only downside is that the type of sensors are limited to a PIRs, Door Contacts, Remote Key Fobs, Keypads and an Outside Bell.

So I've managed to create code to output sensors information to the XRF serial port. The plan is provide a simple interface allowing the XRF to be switched to different alarm modes:

Mode 0 - IDLE (Radio is off, waiting commands from the serial port)
Mode 1- LEARN (Registers a new alarm peripheral, registration is needed so that a peripheral can be easily identified and you don't get messages for peripheral you are interested in)
Mode 2- LISTEN (Radio is listening for a registered sensors to be tigger)
Mode 3 - SEND (Commands can be sent to an existing Control Panel or Bell).

Currently the code supports Mode 0 and Mode 2, as shown in the output below where we switch to Mode 2 and listen for peripheral events. For now I've hardcode the list of registered peripherals because I still need to write the code to save these to the XRF flash memory.

Once a peripheral event is received we dump the ouput which is an 9 character string (this isn't the raw output) but a simplified representation:

AAABBCCCC

AAA - A 3 digit code representing the alarm perhiperal

PIR - PIR,

PAN - Control Panel,

DOR - Door Switch

REM - Remote Fob

KEY - Keypad

BB - runing number indicated the id of the peripheral (I'll probably allow 32 peripheral to be registered).

CCCC - 4 digit number indicator depending on the perhiperal event. For example in the above output 0004 represents a trigger for a PIR or Door Switch. For a Remote Fob or Keypad 0008 represents a disarm. In the output the Remote Fob disarm is always followed by the Control Panel sending a command to the Bell to stop if activated.

I think we can also decode the Freidland Libra+ Door bell and Spectra Outdoor PIR but I don't have these to prove it.

Next steps are to code up the peripheral registration and write a bootloader so that firmware updates can be applied through the serial port. Then I could release the a cut of the firmware.

I received my PI on the Friday although not desperately seeking one I was fortunate to be in the second batch. The packing was simple, consisting of a padded envelope containing in small cardboard box. The PI is smaller than I expected and its actually the same size as credit card which I over laid to prove. The dual USB connectors result in an overall height of around 15mm.

The PI is powered through a micro usb socket and there's no on/off switch which long term makes me dubious of the longevity of the socket. I'm surprised no has produced a usb cable with an in-line switch or may be a case with this feature. If the PI is aimed at the younger generation that I'd expect this to be an very useful feature.

My initial setup consisted of a cheap 1A PSU along with a usb keyboard/mouse and the HDMI output fed to DVI monitor. Deploying the debian build is relatively painless as long as you are PC literature to do so. I found the PI to be slow at booting and Debian although workable slightly basic. If you are looking to use the PI as cheap 'Browsing' solution then its not for you! The default Midori just about manages to display pages and a little patience is required. This does bring me onto another point, if we expect kids to use these for projects then I suppose you would expect to 'google' while developing. Not sure how practical it is to do both on the PI.

Next I moved onto the Arch Linux image, having being introduced to Arch while working on my O2 Joggler and I had higher hopes of its usability although potentially it require more effort to deploy a usable build. Furthermore the ARM port is not as mature as the x86 builds. Arch Linux definitely runs faster although again the booting is slow. I got LXDE up and running although Midori and NetSurf browser failed to start when launched and I didn't have time to debug the issue.

I also tried to use the PI which a powered laptop usb hub (Targus), I plugged an old PS/2 keyboard and mouse into the hub. These wouldn't work with the PI again something that may need to be addressed if we want to these to be deployed in schools where older PC equipment may be prevalent.

I purchased the PI for 2 reasons, firstly as a 'cheap' development board for my own hobby use and secondly as an introduction for my young children to software development.

On the first point I have a number of uses of the PI for my hobby projects. Even then I think theres probably a fair percentage of potential purchasers who may be disappointed as the PI is relatively low spec ARM board.

On the second point the juries out. I'd say there's a fair bit of knowledge required to configure the PI as the kid friendly device, as of now I'd say the software isn't there. However I guess this is where innovation and creativity comes into the picture, so I'll have to find a way to make it kid friendly!

The last 3 weeks have been spent getting up to speed with the Raspi and determining the quickest way of interfacing it with the Nano Alarm Panel (based on the Ciseco XRF board).The end goal was two fold, firstly to read the alarm sensor triggers which later could form the basis of a Raspi Alarm and secondly to be able to arm/disarm my existing SL5 control via the Raspi. I guess another goal was the see if the XRF board could be powered from the Raspi therefore reducing the dependency on an external power source.
As the Nano Alarm Panel already exposes a serial interface the logical choice was to connect the Raspi using the GPIO serial port. However its being widely discussed that the GPIO 3.3v can't supply much current therefore powering the XRF board from the PI may not be possible. Instead I opted to use one of the usb ports because these should be capable of supplying up to 100mA. I used a cheap FDTI serial to usb adaptor which fortunately also had 3.3v output pins to the supply the XRF board.

The XRF powered up with any problems and there have been no stability issues with it powered from the Raspi USB port. This is probably mitigated by the fact the XRF uses a relativity low power RF MCU in the form of the CC1110, looking at the datasheet peak current consumption is less than 40mA.

The next step was to soak test the Nano Alarm Panel code which currently was just dumping the alarm sensor triggers to the serial port. I wrote some C code on the Raspi which read the serial port and dumped the sensor trigger data to a MySQL database. This was complemented with some php scripts running under to lighthttpd to view the data in a browser. The Raspi proved valuable because it allowed me to run numerous long running tests (12 to 24 hours) replacing a PC consuming 200-300 watts of power. These tests resulted in me finding a number a bugs in the Nano Alarm Panel code. Below is the sample output collected while running my tests showing the sensors triggered through a short period in the day. Collecting the sensor triggers can be useful for example I can roughly determine how long my morning runs are by the front door contact trigger.

Having read that the CC1110 also has a built in ambient temperature sensor, I updated the Nano Alarm Panel code to periodically (every 5 minutes) output the temperature, this was done without 1 or 2 point calibration which would have giving better results and as per the TI design note. This change was also made as a result of me wanting to soak test the Debian build as more data would be written to the MySQL database in a 24 hour period, around 300+ per day.

So .... the end results are the Raspi ran 24x7 for over 8 days, collecting around 2700 data readings. Best of all this is running using a £1 ipod power adapter and min usb cable. I stopped the tests after this period so that I could continue developing as I wanted to create additional code to arm/disarm from my phone which should be covered in my next blog. Here's the uptime for the Raspi and the number of data points.

As always I'm on the look out for the next hackable board, my interest turned to the Gooseberry board which essentially is an tablet PCBA. I must commend the Gooseberry founder for sourcing such a board and neogating the price. For me the lack of Ethernet and USB ports means that it didn't fill my requirements. However the idea of sourcing existing PCBA's seems to be good one although this is not easy as most Chinese manufactures will only deal with you if your buying a 1000+ units. Another drawback is that existing PCBA most likely won't have GPIO,I2C,SPI interfaces.

Having spent a few months trying to source a board the closest I could come to a useful board is this pcba.

Hackberry A10 available to buy from here .

Its a small (approx 10cm x 8cm) board supporting a A10 (All Winner) cpu. After drawn out neogations with the manufacture I got them to produce me 2 boards with 1GB ram and 4GB flash which I have just received. The board by default boots Andriod 4.0 and has the following specification:

A10 All Winner

4GB Flash

1GB Ram

2 x USB

1 x Ethernet

1 x Wifi

1 x HDMI

1 x headphone

1 x mic

1 x component video

1 x infra red sensor

1 x 5v power socket

1 x SDHC slot

The board does seem to hold some potential as there seems to be place holders for additional connectors. Furthermore it looks like the board has a multi-purpose layout, as there seems be to markings for the SDHC connector to go on the front or back of the board, similary this also applies to the USB connectors. Sadly theres no GPIO or SATA (unlike the Mele boxes).

Here's a further update about the board.

My first attempt at booting Ubuntu and Puppy Linux is here.

Hackberry A10 available to buy from here .

For the last few weeks I've been very busy mainly due to the interest in the board and more importantly debugging the hardware/software to determine what some of the missing connectors and solder points are for. Unfortunately one of the boards wasn't reporting the 1GB RAM and has to be sent back, so I'm only left with one board.

Well here's the progress so far, the serial port is located on the right above the power socket and hopefully the boards can be manufactured with the connector in place. I located two missing connector points for switches either side of the infra-red dectector. One turned out to be for a power down/up or sleep mode. The other is to force the board on boot up into FEL mode, having almost bricked my board a number times I was more than happy to find this. So now the board can easily be reflashed using Livesuit which I can confirm works. Next to the FEL recovery switch solder points are what look like solder points for a USB connector, unfortunately I haven't had time to test out if its active or not or whether the wifi board is using the USB port. Another plus point for the board is that most of the solder points easily accessible for soldering. Theres also some interesting connection points on the back of the pcb which I haven't explored yet!

The "Boot1" seems to be interesting as the USB ports are activated within "Boot1" as shown below, I have a feeling that it should be possible to boot from the USB as well from SD card. When I can get sometime I will investigate this further as I think development must be done with the board some how connected to a PC instead of wearing the internal Flash away. Hopefully more news to follow.

HELLO! BOOT0 is starting!
boot0 version : .3.0
dram size =1024
Succeed in opening nand flash.
Succeed in reading Boot1 file head.
The size of Boot1 is 0x00036000.
The file stored in 0X00000000 of block 2 is perfect.
Check is correct.
Ready to disable icache.
Succeed in loading Boot1.
Jump to Boot1.
[       0.146] boot1 version : 1.3.1a
[       0.146] pmu type = 3
[       0.146] bat vol = 0
[       0.177] axi:ahb:apb=3:2:2
[       0.177] set dcdc2=1400, clock=1008 successed
[       0.179] key
[       0.191] no key found
[       0.191] flash init start
[       1.570] flash init finish
[       1.571] fs init ok
[       1.572] fattype FAT16
[       1.572] fs mount ok
[       1.578] script finish
[       1.580] power finish
[       1.584] BootMain start
[       1.584] 0
[       1.593] usbdc_vol = 4000, usbdc_cur = 0
[       1.593] usbpc_vol = 4000, usbpc_cur = 0
[       1.595] init to usb pc
[       1.598] set pc
[       1.601] key value = 0
[       1.603] recovery key high 6, low 4
[       1.607] unable to find fastboot_key key_max value
[       1.613] test for multi os boot with display
[       1.616] show pic finish
[       1.619] load kernel start
[       1.639] load kernel successed
[       1.639] start address = 0x4a000000
[       1.641] power exit detect
[       1.644] usb exit d

After a couple of hours of debugging I final got the MK802 Ubuntu 12.04 image working on the Hackberry. So thanks to guys on the miniand forums for create the images, in the end just a simple tweak of deploying the script.bin from the pre-installed Android got the image to boot. Once booted and after log-on I manually enabled the Ethernet connectivity.

As this is a pre-built image the wifi wasn't detected correctly, however I was pleased to make such quick progress. The build seems to be fairly snappy and its good to see it reporting the full 1GB memory. Of course further work is required to get a fully functioning build.

I also spent some time getting the pre built version of Puppy Linux to boot based on this article on liliputing. Again faced similar issues to the Ubuntu build but got there in the end! As mentioned in the liliputing article the user interface is not as slick as Ubuntu but I can see a certain attraction to Puppy because of its speed. The main draw with this pre-built image is that its only reporting 512Mb RAM.

Having been intrigued by the boot messages that appear upon the board booting I thought I would take some time to look at this further. As described on numerous internet sites the A10 first loads the bootloader boot0 to do some basic initialisation and then loads the secondary bootloader boot1. It seems boot1 can do many things like display a logo or load a linux kernel. In our case boot1 seems be contained in the file boot.axf. So here is the output from this board.

HELLO! BOOT0 is starting!
boot0 version : .3.0
dram size =1024
Succeed in opening nand flash.
Succeed in reading Boot1 file head.
The size of Boot1 is 0x00036000.
The file stored in 0X00000000 of block 2 is perfect.
Check is correct.
Ready to disable icache.
Succeed in loading Boot1.
Jump to Boot1.
[       0.146] boot1 version : 1.3.1a
[       0.146] pmu type = 3
[       0.146] bat vol = 0
[       0.177] axi:ahb:apb=3:2:2
[       0.177] set dcdc2=1400, clock=1008 successed
[       0.179] key
[       0.191] no key found
[       0.191] flash init start
[       1.570] flash init finish
[       1.571] fs init ok
[       1.572] fattype FAT16
[       1.572] fs mount ok
[       1.578] script finish
[       1.580] power finish
[       1.584] BootMain start
[       1.584] 0
[       1.593] usbdc_vol = 4000, usbdc_cur = 0
[       1.593] usbpc_vol = 4000, usbpc_cur = 0
[       1.595] init to usb pc
[       1.598] set pc
[       1.601] key value = 0
[       1.603] recovery key high 6, low 4
[       1.607] unable to find fastboot_key key_max value
[       1.613] test for multi os boot with display
[       1.616] show pic finish
[       1.619] load kernel start
[       1.639] load kernel successed
[       1.639] start address = 0x4a000000
[       1.641] power exit detect
[       1.644] usb exit d

As we can see boot0 loads and initialises the SDRAM Ram and then jumps to Boot1. Boot1 checks to see if the FEL Recovery button is pressed by the following

[ 0.179] key
[ 0.191] no key found

While continuing the remaining steps in boot1 until [ 1.584] 0 it also waits for key input from the serial port. In fact the '0' is the ASCII key value it detected, in this case zero (no key pressed). So what happens if we hold a key pressed while the board is booting?

If we keep key '1' pressed while the board is booting we get this

Jump to Boot1.

[ 0.146] boot1 version : 1.3.1a

[ 0.146] pmu type = 3

[ 0.146] bat vol = 0

[ 0.177] axi:ahb:apb=3:2:2

[ 0.177] set dcdc2=1400, clock=1008 successed

[ 0.178] key

[ 0.191] no key found

[ 0.191] flash init start

[ 1.568] flash init finish

[ 1.569] fs init ok

[ 1.570] fattype FAT16

[ 1.570] fs mount ok

[ 1.576] script finish

[ 1.577] power finish

[ 1.582] BootMain start

[ 1.582] 49

[ 1.582] part count = 2

[ 1.585] USB Device!!

[ 1.588] USB Connect!!

[ 1.643] uSuspend

If we now connect the lower usb port to a PC we get this

[ 188.626] uSuspend

[ 188.701] uSuspend

[ 188.768] usb_device: Set Address 0x0x00000006

[ 189.788] usb_device: Get MaxLUN

And for this board 2 usb drives should appear in Windows/Linux showing the boot nand partition and I think the Android data partition. In fact it will shown every FAT partition it can recognise from the NAND chip. I was hoping that it would also show FAT partitions for the SD card/USB drive but it doesn't seem to be the case. This feature is used to facilitate the coping of files to the boot partition while developing the bootloader code without having to re-flash the whole chip. For me this is an alternative way to get to the boot partition files or to copy files from another FAT partition. To get out of this mode press the FEL recovery button and the board reboots.

If we try key '2' we get this

[ 0.221] BootMain start

[ 0.221] 50

[ 0.222] Jump to fel

The boot1 jumps to FEL recovery mode to be used with Livesuite.

If we try key '3' we get this

[ 0.221] BootMain start

[ 0.221] 51

[ 0.222] welcome to key value test

[ 0.225] press any key, and the value would be printed

[ 0.231] press power key to exit

Seems to be some kind of test mode for detecting button presses in our case we have just one button the FEL recovery button to test.

[ 47.254] key value = 15

[ 47.257] key value = 63

Unfortunately none of the other numerical keys seems to have any effect while boot1 is booting.

I've spent some time attempting to get the Hackberry configured as a Wireless Access Point. The on-board wifi module is the based on the RealTek RTL8188CU. The official driver documentation indicates the driver support SoftAP mode, supporting up to 8 clients at a max speed of 54Mbps

Initially I tried using hostapd on a pre-built MK802 Linaro build, hostapd fails to set the wifi driver (8192cu.ko) in to master mode. The cause of the problem seems to be hostapd supplied in the Linaro build. The problem can be overcome by compiling the hostpad supplied with the driver from the RealTek site (version 3.4.4_4749). A pre-compiled hostpad can be downloaded from this zip hackberry_ap.zip along with all other files required for your set-up. Alternatively you can attempt to compile hostapd yourself on the hackberry as follows:

Inside the tar file is a file wpa_supplicant_hostapd-0.8_rtw_20120803.zip, extracting this reveals a hostpad directory, copy the directory to your hackberry. I'm assuming you are running a flavor of ubuntu therefore you need to  install a build environment by "aptitude install build-essential". Now run the Make file in the hostpad directory.

Before we can use the new hostpad a further 3 steps need to be undertaken.

1. Turn off power save mode for the wifi driver, this can be done by creating the file /etc/modprobe.d/8192cu.conf on the hackberry with the line below and reboot:

options 8192cu rtw_power_mgnt=0 rtw_enusbss=0

2. Install a dhcp server, I used isc-dhcpd-server (sudo apt-get install isc-dhcp-server) and configure by editing /etc/dhcp/dhcpd.conf. A sample dhcpd.conf is include in the download zip. Assuming wlan0 is configure with a static ip address of 10.0.0.1 here's the lines to add:

subnet 10.0.0.0 netmask 255.255.255.0 {
        range 10.0.0.2 10.0.0.10;
        option domain-name-servers 8.8.4.4;
        option routers 10.0.0.1;
}

The domain-name-servers tag although configure will not function as there is no bridge between wlan0 and eth0 at this stage.

3. Last step is to create a hostapd.conf file, again a sample is included the download zip. The essential setting are:

##### hostapd configuration file ##############################################
interface=wlan0
ctrl_interface=/var/run/hostapd
ssid=hackberry
channel=6
wpa=2
wpa_passphrase=87654321
#bridge=br0

Change the ssid, channel and wpa_passphrase as required.

To test this simple set-up it's best install a web server (lighttpd or apache2) on the hackberry because at this stage there is no ip routing configured to bridge eth0.

Now to run hostapd we have to configure wlan0 with a static ip address, restart the dhcp server and start the compiled hostapd with your configuration.

ifconfig wlan0 up 10.0.0.1 netmask 255.255.255.0 
service isc-dhcp-server restart
./hostapd hostapd.conf -B

If everything goes to plan the SSID should be visible to your wifi client, connect to it and launch a browser. Access http://10.0.0.1/ and the default web server page is appear.

Another useful feature is to be able to bridge wlan0 to eth0, in my case this allows me to provide a internet gateway to the wifi clients through my adsl router. I initially tried the bridge feature provide the RealTek driver unfortunately I couldn't get it to route packets correctly. The alternative is to use ip tables, the main drawback is that kernel needs to be recompiled with ip tables support enabled. Include in the download zip is sample .config with ip tables support enabled (kernal version 3.0.36). The options you have to enable are:

Networking ---->
Networking options ---->
Network packet filtering framework (Netfilter)--->
Core Netfilter Configuration ---->
<*> Netfilter connection tracking support
<*> Netfilter Xtables support (required for ip_tables)
<*> "NFLOG" target support
<*> "conntrack" connection tracking match support
<*> "state" match support
IP: Netfilter Configuration --->
<*> IPv4 connection tracking support (required for NAT)
<*> IP tables support (required for filtering/masq/NAT)
<*> Packet Filtering
<*> REJECT target support
<*> Full NAT
<*> MASQUERADE target support
<*> Packet mangling

Once you have deployed the new kernel, you may need to update dhcpd.conf (domain-name-servers) with the dns server of your adsl/dsl router if eth0 is assigned through dhcp. This will allow local ip addresses to be resolved by your adsl/dsl router. The next step is to add ip table rules to route traffic between wlan0 and eth0 and enable ip forwarding.

iptables --flush
iptables --table nat --flush
iptables --delete-chain
iptables --table nat --delete-chain
iptables --table nat --append POSTROUTING --out-interface eth0 -j MASQUERADE
iptables --append FORWARD --in-interface wlan0 -j ACCEPT
sysctl -w net.ipv4.ip_forward=1

I suggest restarting the isc-dhcp server and hostapd before testing. If successful your wifi clients should have access to other devices on your internal network and if configured internet access.

After setting up the Access Point, I'd thought I would devote some time on integrating the Nano alarm panel with the Hackberry. The end goal was to arm/disarm from my Andriod phone within the vicinity of my home by connecting to the access point.

For those that don't know the Nano alarm panel was my attempt to interface with my wireless home alarm system. The Nano is based on Ciesco's underrated XRF module and uses the TI CC1110 chipset. The CC1110 combines RF with an 8051 mcu and offers an number of features including gpio, spi, ic2, a12 bit-adc and uarts. As a side note the XRF has reportedly reached a range of over 1Km over 868Mhz. I've written custom firmware that is deployed on the XFR to decode the wireless alarm protocol and to communicate with the Hackberry. As the CC1110 has no usb interface (unlike the CC1111) I decided to interface using the CC1110's uart interface. The Hackberry is easily interfaced to the XRF using a serial ttl-usb adapter (in my case a CP1202). Later on I might explore the possibility of using the hackerry's on-board serial port because it is voltage compatible. The added advantage of the serial ttl-usb adapter is that I can also power the XFR through adapter as the CC1110 is a very low power device.

The Hackberry is deployed with lighttpd along with some custom php scripts and c code to read/write commands via the serial port to the XRF. To test the stability of the Lubuntu build I've also deployed mysql and included addition code to capture all alarm sensor triggers and periodically record (every 5 mintues) the ambient temperature as reported by the CC1110. The plan is to leave this running 24x7. As side note I found that minicom fails to work with the usb serial adapter (/dev/ttyUSB0) but I found a replacement microcom (apt-get install microcom) that works fine.

Currently lighttpd presents a simple page which can be viewed in the phones web browser displaying the 3 buttons to arm (red) , part-arm (yellow) or disarm (green). Longer term the intention is to develop an android app to by-pass lighttpd. Here's a badly made video showing it in action next to the alarm panel.

There seems to be demand for a minimal headless debian wheezy image for the Hackberry. So here is a pre-built image that I've created using this armhf rootfs and compiling a 3.0.36 kernel. This should easily fit on a 1GB SD card as its fairly light weight however the pre-built image is currently for a 4GB card. You can dd the image to a smaller SD card and subsequently mend the ext4 partition. Image works on the 1Gb model haven't got a 512Mb version to test with. To deploy the image to your SD card use the following commands, you can find the <device> of your SD card by 'df -h'.

gunzip debian_wheezy_3.0.36.img.gz
dd if=debian_wheezy_3.0.36.img of=/dev/<device>
sudo sync

Once the imaging is complete the SD card will contain a small fat16 partition for booting and the remaining space allocated to the rootfs (ext4). You change the debian configuration as you like before booting. The default image is configured for eth0 (dhcp) and ssh enabled. You can configure eth0 to a static ip address by editing /etc/network/interface. It is possible to enable wifi by editing /etc/modules to load 8192cu.ko, configuring /etc/network/intefaces for wlan0.

Note: I have created a new uboot based on the lastest source, the two files sunxi-spl.bin and u-boot.bin can be download from here. Patch these to the SD card image:

sudo dd if=sunxi-spl.bin of=/dev/<drive> bs=1024 seek=8
sudo dd if=u-boot.bin of=/dev/<drive> bs=1024 seek=32
sudo sync

Now boot the Hackberry with the SD card if all is ok you will need to find the ip address of the Hackberry and ssh as root (password is password) eg:

ssh root@<ip address>

You should now be presented with a shell

Linux (none) 3.0.36+ #39 PREEMPT Sun Sep 23 14:52:17 BST 2012 armv7l

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Fri Jan 1 00:00:50 2010 from mtx512-inspiron-620.lan
root@(none):~#

Free memory is currently showing at around 800K:

root@(none):~# free -m

total used free shared buffers cached

Mem: 814 30 784 0 2 12

-/+ buffers/cache: 15 799

Swap: 0 0 0

We can probably release more memory by removing unwanted kernel modules (eg mali) since this is a headless image.

I took Toby's Linaro build for the MK802 and patched it to work for the Hackberry. Thanks to Tobay for the work he put into creating the build.

You have two options for getting an image to SD card:

1. Use download my pre-built image

The image is for the 1GB board and contains my latest uboot and a 3.0.36+ kernel compiled to work with the uboot. Kernel is now compiled with hard float resulting in improved performance. It is for a 4GB SD card but the ext4 partition is only 3.5GB. Note: not all 4GB SD cards are 4GB, they may be 3.7,3.8 etc which may mean your dd may fails early. However since we only use 3.6GB hopefully it is ok. If it fails to boot try a 8GB card if you can or re-adjust the partitions on linux after creating the image.

gunzip linaro_hf_3.0.36_1gb.img.gz
dd if=linaro_hf_3.0.36_1gb.img of=/dev/<device>
sudo sync

2. Build from scratch as below:

Download Toby's last image from linaro-alip-armhf-t4.7z. Extract image from the zip to reveal linaro-alip-armhf-t4.img.

Download my uboot files sunxi-spl.bin and u-boot.bin from here.

Use the boards existing script.bin or download from here script.bin.

Copy image and uboot files to SD card:

sudo dd if=linaro-alip-armhf-t4.img of=/dev/sdc

sudo sync

sudo dd if=sunxi-spl.bin of=/dev/sdc bs=1024 seek=8

sudo dd if=u-boot.bin of=/dev/sdc bs=1024 seek=32

sudo sync

I suggest building a kernel to ensure it works with uboot files and copy that across to the SD card.

Remove SD card and re-insert to mount drives.

Replace existing evb.bin on fat16 partition with your script.bin, eg on ubuntu do:

cp script.bin /media/<drive label>/evb.bin

sync

Now to test it boots:

Remove SD card and place in hackberry, connect hdmi cable to your TV/monitor and boot. Fingers crossed after a while the linaro desktop should appear. Plug in a usb mouse & keyboard and away you go.

One of the outstanding items on my long of list of 'things to do with the Hackberry' was to get my Huawei E173s 3G modem working under Debian. This allows the Hackberry to used for remote deployments where LAN/WLAN is not possible. Furthermore there is the possibility of using the modem for reading and writing SMS messages. You can use these instructions as a template for other modems types and/or or other Linux variants.

First step is to enable ppp support in the kernel as below:

[*] Network device support --->

<M> PPP (point-to-point protocol) support
[*] PPP filtering
<M> PPP support for async serial ports
<M> PPP support for sync tty ports
<M> PPP Deflate compression
<M> PPP BSD-Compress compression
<M> PPP on L2TP Access Concentrator
<M> PPP on PPTP Network Server

Fortunately in my debian image the kernel is configured to include the ppp modules. Next step is to install the package usb_modeswitch which allows switching from usb storage mode to modem mode. Without this package plugging the modem into the usb port result in it being recognised as a usb storage device. At the same time we can retrieve the package usbutils and wvdial so that we run the command lsusb and configure the modem.

apt-get install usb_modeswitch
apt-get install usbutils
apt-get install wvdial

To switch modes we need to add a new rule for the modem (based on it's usb id), you can skip this step if your modem does not have usb storage support. For the E173s this means creating the file /etc/usb_modeswitch.d/12d1:1c0b with following contents:

########################################################
# Huawei E173s
DefaultVendor= 0x12d1
DefaultProduct= 0x1c0b
TargetVendor= 0x12d1
TargetProduct= 0x1c05
CheckSuccess=20
MessageEndpoint= 0x0f
MessageContent= "55534243123456780000000000000011062000000100000000000000000000"

Next install the kernel modules for usb modem support and ppp.

insmod /lib/modules/3.0.36+/kernel/drivers/usb/serial/usbserial.ko

insmod /lib/modules/3.0.36+/kernel/drivers/usb/serial/usb_wwan.ko

insmod /lib/modules/3.0.36+/kernel/drivers/usb/serial/option.ko

insmod /lib/modules/3.0.36+/lib/crc-ccitt.ko

insmod /lib/modules/3.0.36+/kernel/drivers/net/slhc.ko

insmod /lib/modules/3.0.36+/kernel/drivers/net/ppp_generic.ko

insmod /lib/modules/3.0.36+/kernel/drivers/net/bsd_comp.ko

insmod /lib/modules/3.0.36+/kernel/drivers/net/ppp_deflate.ko

insmod /lib/modules/3.0.36+/kernel/drivers/net/ppp_async.ko

Fingers crossed we can plug the modem into the top usb port of the hackberry. Dmesg should report some thing similar to this:

[ 2482.070000] option1 ttyUSB0: GSM modem (1-port) converter now disconnected from ttyUSB0

[ 2482.100000] option 2-1.2:1.0: device disconnected

[ 2482.140000] option1 ttyUSB1: GSM modem (1-port) converter now disconnected from ttyUSB1

[ 2482.170000] option 2-1.2:1.1: device disconnected

[ 2482.200000] option1 ttyUSB2: GSM modem (1-port) converter now disconnected from ttyUSB2

[ 2482.250000] option 2-1.2:1.2: device disconnected

[ 2528.090000] usb 2-1.2: new high speed USB device number 5 using sw-ehci

[ 2528.590000] scsi4 : usb-storage 2-1.2:1.0

[ 2528.620000] scsi5 : usb-storage 2-1.2:1.1

[ 2530.960000] scsi 5:0:0:0: Direct-Access HUAWEI SD Storage 2.31 PQ: 0 ANSI: 2

[ 2530.990000] scsi 4:0:0:0: CD-ROM HUAWEI Mass Storage 2.31 PQ: 0 ANSI: 2

[ 2531.050000] sd 5:0:0:0: [sda] Attached SCSI removable disk

[ 2531.090000] sr0: scsi-1 drive

[ 2531.150000] sr 4:0:0:0: Attached scsi CD-ROM sr0

And lsusb reports (note 'modem on', if 'modem off' then something is wrong):

root@(none):~# lsusb

Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

Bus 002 Device 002: ID 05e3:0608 Genesys Logic, Inc. USB-2.0 4-Port HUB

Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

Bus 004 Device 002: ID 0bda:8176 Realtek Semiconductor Corp. RTL8188CUS 802.11n WLAN Adapter

Bus 002 Device 006: ID 12d1:1c05 Huawei Technologies Co., Ltd. E173s 3G broadband stick (modem on)

Last step is to configure wvdial , I found the default configuration in /etc/wvdial.conf doesn't work so here are my settings, thanks to koi-sama on the miniand forums for help with configuration. Replace tmobile section with your settings, Init2 is APN and the Username and Password are self explanatory.

[dialer defaults]

Modem = /dev/ttyUSB0

Baud = 460800

Dial Command = ATD

Init1 = ATE1

Phone = *99***1#

Stupid Mode = 1

New PPPD = 1

Dial Attempts = 10

Dial Timeout = 10

[Dialer tmobile]

Modem = /dev/ttyUSB0

Init2 = AT+CGDCONT=1,"IP","general.t-mobile.uk"

Phone = *99#

Stupid mode = yes

Username = ""

Password = ""

Dial Attempts = 0

Now we can attempt to connect

root@(none):~# wvdial tmobile

--> WvDial: Internet dialer version 1.61

--> Initializing modem.

--> Sending: ATE1

ATE1

--> Sending: AT+CGDCONT=1,"IP","general.t-mobile.uk"

AT+CGDCONT=1,"IP","general.t-mobile.uk"

--> Modem initialized.

--> Sending: ATD*99#

--> Waiting for carrier.

ATD*99#

CONNECT

--> Carrier detected. Starting PPP immediately.

--> Starting pppd at Sat Jan 2 23:48:07 2010

--> Pid of pppd: 2099

--> Using interface ppp0

--> pppd: )

--> local IP address 31.126.31.57

--> pppd: )

--> remote IP address 10.64.64.64

--> pppd: )

--> primary DNS address 149.254.230.7

--> pppd: )

--> secondary DNS address 149.254.192.126

--> pppd: )

ifconfig reports

root@(none):~# ifconfig

ppp0 Link encap:Point-to-Point Protocol

inet addr:31.126.31.57 P-t-P:10.64.64.64 Mask:255.255.255.255

UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1

RX packets:8 errors:0 dropped:0 overruns:0 frame:0

TX packets:9 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:3

RX bytes:128 (128.0 B) TX bytes:185 (185.0 B)

When I get time I will look into reading/writing sms messages from the modem.

I've had quite a few requests to include or create kernel modules for the debian image. So here are instruction to compile a kernel. There's plenty of information on the web for compiling kernels for the A10 and its not that difficult. All you require is a machine with Linux. Its best to do some background reading on using 'git' if you are not familiar with it. These instructions are for Ubuntu.

I've updated these instructions so that they use hard float instead of soft float which should give an increase in performance. 'arm-linux-gnueabi' is replaced with 'arm-linux-gnueabihf'

First retrieve the build and cross compiler tools:

sudo apt-get install gcc-arm-linux-gnueabihf build-essential git uboot-mkimage libncurses5-dev

Next create a directory where you want build the kernel and retrieve the kernel source from git. This will take some time. Note the old repository was git://github.com/amery/linux-allwinner.git it has now move to git://github.com/linux-sunxi/linux-sunxi.

mkdir kernel

cd kernel

git clone git://github.com/linux-sunxi/linux-sunxi

Now switch to branch you are interested in, the current stable is linux-sunxi. For debian I'm currently using revision 23e5456879db0175f571dec43095c49e181e0b10 (3.0.36+). Note kernels version beyond 3.0.36+ ethernet (eth0) on the hackberry fails to initialise correctly, see my patch at the end of the blog for a temporary fix.

cd linux-sunxi

git checkout 23e5456879db0175f571dec43095c49e181e0b10

next step is to create a default kernel config, this creates a .config file.

make ARCH=arm sun4i_defconfig

now to add additional modules or change kernel settings do

make ARCH=arm menuconfig

Now can compile the kernel and modules

make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- -j3 uImage

make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- -j3 INSTALL_MOD_PATH=output modules

make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- -j3 INSTALL_MOD_PATH=output modules_install

Last step is to copy the kernel (uImage) to the boot fat partition and the kernel modules to the ext4 partition. Note keep track of the kernel version that is in .config as this will determine which modules directory has to be copied across. Here is the example for the debian image and git revision 23e5456879db0175f571dec43095c49e181e0b10.

cp arch/arm/boot/uImage /media/BOOT/

cp -rp output/lib/modules/3.0.36+/kernel /media/debian/lib/modules/3.0.36+

---------------------------------------------------------------------------------
Patch for ethernet initialisation failure:

--- a/drivers/net/sun4i/sun4i_wemac.c

+++ b/drivers/net/sun4i/sun4i_wemac.c
@@ -53,7 +53,7 @@
#define DRV_VERSION "1.01"
#define DMA_CPU_TRRESHOLD 2000
#define TOLOWER(x) ((x) | 0x20)
-#define PHY_POWER 0
+#define PHY_POWER 1
/*
* Transmit timeout, default 5 seconds.
*/
@@ -1563,7 +1563,8 @@ static int wemac_phy_read(struct net_device *dev, int phyaddr_unused, int reg)
writel(0x1, db->emac_vbase + EMAC_MAC_MCMD_REG);
spin_unlock_irqrestore(&db->lock, flags);

- wemac_msleep(db, 1); /* Wait read complete */
+ // wemac_msleep(db, 1); /* Wait read complete */
+ udelay(150); /* 100 */

/* push down the phy io line and read data */
spin_lock_irqsave(&db->lock, flags);
@@ -1596,7 +1597,8 @@ static void wemac_phy_write(struct net_device *dev,
writel(0x1, db->emac_vbase + EMAC_MAC_MCMD_REG);
spin_unlock_irqrestore(&db->lock, flags);

- wemac_msleep(db, 1); /* Wait write complete */
+// wemac_msleep(db, 1); /* Wait write complete */
+ udelay(150); /* 100 */

spin_lock_irqsave(&db->lock, flags);
/* push down the phy io line */

Having not seen any benchmarks for running Java on a A10 device, I thought I would performed some benchmarks using dacapo bench suite. Currently the Oracle JDK for ARM is only available for armel, armhf is reportedly faster therefore I conducted these tests with OpenJDK 7 (IcedTea7 2.1.2) using my debian wheezy image with a hard-float compiled kernel.

OpenJDK 7 includes support for 3 JVM's - JamVM, Cacao and Zero/Shark. Unfortunately Cacao failed to run with dacapo therefore there it is excluded from our tests. OpenJDK7 is currently classed as 'testing' in the Debian repository which may explain the Cacao failure.

Below are the results for JamVM and Zero, times are in milliseconds.

Dacapo Test	JamVM	Zero/Shark
avrora	278216	196867
eclipse	1173809	837472
fop	46093	35759
jython	553172	373691
luindex	56140	52659
lusearch	243673	202925
pmd	88551	97203
sunflow	1283857	729727
tomcat	131739	FAILED
xalan	305040	255660

Overall Zero performs better than JamVM apart from the failure in the tomcat test. There is another JVM available for OpenJDK that is Avain it's a small lightweight and fast JVM. There is a Arm port available in the Debian repository unfortunately it is classed as 'unstable' and I couldn't get it to execute with dacapo. It is possible to compile Avain from source unfortunately I didn't have time to do so.

If we compare these results to similar benchmarks for the Raspberry PI, then OpenJDK 7 does seem to redeem itself on the A10 platform. Although we are not comparing apples with apples (cortex A8 v ARM1176) it is encouraging to see that the figures compete with Oracle JDK 7 (amel) albeit on the PI. Oracle JDK 7 is know to perform better than OpenJDK and it is a shame we still don't have an armhf version to benchmark against. Hopefully Oracle will release something soon!

As discovered by Adrian on the miniand forums, the Hackberry has an on-board USB Hub (Genesys Logic GL850G) resulting in the board providing up to 6 usb ports. 1 port is used by the wifi module, another are 2 exposed by the double connector next to the HDMI port. Out of the remaining 3, 2 are available through solder pads on the pcb.

One is located on the rear of the board as shown below.
This one seems better suited to a on board module such a bluetooth or another wifi. The difficultly arises from sources a module that matches the dimensions of the 4 pin layout.

The second port is located on the front side of the board near to the SD card and is easily recognised by the tracing lines for a Type A USB connector.You could try to populate this one with a Type A connector although because the solder pads aren't holed there nothing to keep the connector in place apart from soldering the connector housing to their solder pads.

After some deliberation I decided to see if it was possible to solder a 0.1" 4 way pcb header to the four usb pads. This solution allows for a plug-n-play style usb port connector, use it when you want! The problem of using a stand vertical pcb header like this is that there is little support for it once solder due to the lack of through holes for mounting. To overcome this I used a right angled version of the connector which first was soldered the wrong way (ie the pin without the plastic support the soldered) and after successful soldering I prised off the plastic supports from the vertical pins.

The next stage was to create a pluggable usb connector, this required a 4 way 0.1" right angle header, a Type A usb connector and a small strip of vero board. I soldered the 4 way header and Type A connector onto the vero board.

Once done I could plug the pluggable usb connector onto the pins on the hackberry using a jump cable made from two 4 way 0.1" female connectors.

Last step was to test it worked, for this I plugged in a usb stick.

When I don't require the usb port I can easily remove the jump cable.

I spent some time creating a working XBMC image for the Hackberry because of the increased interest generated on the xbmc forum. Firstly a big thanks to numerous contributors (empatzero,rellla,shivansps,gimli) on the xbmc forum for getting the cedar libaries integrated and getting a build-able xbmc for the A10 soc.

The latest compiled version of xbmc is towards the end of this post if just want to download it works on hackberry and should work on any distro with fb support (for non hackberry deployment).

Standard disclaimer at this point, its an unsupported release as there are many untested/non-working features but hopefully gives you a taste of progress or starting point for further improvements. Furthermore there's nothing stopping you getting this running on other A10 devices, at minimum you will need to replace script.bin, uboot and if no ethernet remove this from /etc/network/interfaces otherwise there will be a long delay before you see a command prompt on the screen. Lastly you may also need to replace the kernel.

To start with I took guillaume ubuntu 12.10 (armhf) build and reworked it so that it boots for the Hackberry from an SD card using a 3.0.42+ kernel (revision cbf3d41b7ed513a743854fde1ca0b5c4d0f11610 + my wemac patch). Again thanks to guillaume for such a useful headless build. One of the highlights of this build is that it presents an on screen command console, meaning there is no longer a reliance on ssh for a command shell. The main issue with the build seems to be graphical tearing while editing at the command line, something I can live for now. The build still starts an ssh daemon if you need access through Ethernet (host name is hackberry, try ssh root@hackberry). There's nothing stopping you using the image without xbmc, although it currently it assumes a default resolution of 1280 x 720 which is required by xbmc.

I created an armhf build of xbmc which was compiled on the Hackberry (taking numerous hour to complete, something to leave overnight). I mainly followed the instructions here.

Download the image (its quite large 722Mb) and dd (or equivalent in Windows) to an SD card, the image expands to 4GB but only takes around 2GB and should easily fit on a 4GB card. Repartition the ext3/ext4 partition to make use of the remaining space on your SD card. Instructions to dd the image:

gunzip
dd if=xbmc_hackberry.img of=/dev/<device> bs=1M
sudo sync

You should alter script.bin (on the FAT partition) to contain a different mac address if you intend to use ethernet, more instruction here.

Boot the Hackberry with the newly created SD card and hopefully the command console should appear on your display:

Ubuntu 12.10 hackberry tty1

hackberry login :

To logon user/password is root and to start xbmc

cd /allwinner/xbmc-pvr-binhf/lib

xbmc/xbmc.bin

Fingers crossed the xbmc log should appear followed by the main screen. Plug-in a keyboard/mouse to navigate.

Short video to demonstrate how well it runs (unfortunately no sound as I was using a hdmi to vga adapter).

I tried a 1080p video (.mov) which it played without any problems.

To enable audio, go to setting and cycle through audio adapters and until sound is heard. For me thiss worked for hdmi and also through the hackberry AV port (the socket nearest to the usb ports).

I couldn't exit xmbc using the menu options, 'Power off System' occasionally worked but dropped to the command line. In the end I resorted to ssh'ing and powering down (shutdown -Ph now).

I compiled a new xbmc version based on commits as of 01-12-2012 from empatzero's repo. Main change as per commit log is:

FIXED MPEG4 CODECS: FLV1, WMV2, DIVX4, DIVX4, DIVX5, XVID.

Download xbmc_01_12_2012.tar.gz, which contains the contents of the allwinner directory and replace with the existing one on the image. Beware the allwinner directory is owned by root on the image. Copy the downloaded tar file to the hackberry and then untar, example below.

cd /
tar xvf xbmc_01_12_2012.tar,gz

For those looking to make modifications or build from source, the repository I used is git://github.com/empatzero/xbmca10 along with following the instructions here to a greater extent.

Having spent many hours attempting to get a custom kernel booting for the factory Android image, I found that is was easier to first create an factory Android image that would boot from an SD card. The main advantage is that it removes the arduous steps of packaging a complete image and then re-flashing to Nand for each small change. It also opens up the possibility of booting other Android distributions from an SD card.

To start with I created a mirror image of the nand paritition on an SD card, to do this requires a linux installation. The nand partitions range from A-K as are covered in more detail here. I used gparted to create the partitions with the correct sizes as below, it is important that you leave 16MB free at the start of the SD card for uboot (shown by 'unallocated' partition) . You need to create an extended partition (shown by /dev/sdc4) in order to create more than 4 partitions.

You need to create an additional partition on the SD card to represent the extrernal sd card /mnt/extsd, I created a FAT32 partition which becomes /dev/sdc13 (mmcblk0p13).

Next step is to copy across all the nand partitions from the hackberry. This can be done by booting the hackberry with a linux distro and using the linux dd command to copy the partitions to files. I copied the partitions on to a usb stick (needs to be at least 4GB) as below:

dd if =/dev/block/nanda of=nanda

dd if =/dev/block/nandb of=nandb

dd if=/dev/block/nandc of=nandc

...

dd if=/dev/block/nandk of=nandk

Once all the nand files are created we can 'dd' the files to the SD card. The boot partition file nandc is not copied because we need to extract the rootfs from it and create a ext4 partition. The bootloader file nanda is also not copied as we create our uboot on FAT16 partition (/dev/sdc1). Assuming the SD card shows up as /dev/sdc I executed the following (amend /dev/sdc with correct device name for your SD card).

sudo dd if=nandb of=/dev/sdc2

sudo dd if=nandd of=/dev/sdc5 bs=1M

sudo dd if=nande of=/dev/sdc6

sudo dd if=nandf of=/dev/sdc7

sudo dd if=nandg of=/dev/sdc8

sudo dd if=nandh of=/dev/sdc9

sudo dd if=nandi of=/dev/sdc10

sudo dd if=nandj of=/dev/sdc11

sudo dd if=nandk of=/dev/sdc12 bs=1M

sudo sync

Next I extracted the ramdisk rootfs from the nandc file, fortunately I have done this for you. Download the file android_sd.tar.gz, it contains all the additional files required to create a bootable sd card. If your interested how I extract the kernel and rootfs I used the split_bootimg.pl utility, further info here. I also fixed the files init.sun4i.rc and ueventd.sun4i.rc so that they refer to the sdcard paritions /dev/ /dev/mmcblk0pX instead of /dev/nandX.

The mapping between nand and mmcblk0p are shown below

nanda -> mmcblk0p1
nandb -> mmcblk0p2
nandc -> mmcblk0p3
mmcblk0p4
nandd -> mmcblk0p5
nande -> mmcblk0p6
nandf -> mmcblk0p7
nandg -> mmcblk0p8
nandh -> mmcblk0p9
nandi -> mmcblk0p10
nandj -> mmcblk0p11
nandk -> mmcblk0p12

Take the nandc file from the zip file and dd it to the correct SD card parition, in my example it is /dev/sdc eg:

sudo dd if=nandc of=/dev/sdc3

I then changed all references in the script files on the system partition (/dev/sdc5 in my example) from /dev/nandX to /dev/mmcblk0pX. The files to amend are:

./etc/vold.fstab
./bin/preinstall.sh
./bin/sop.sh

You need to edit ./etc/vold.fstab and replace the /mnt/extsd with the following:

dev_mount extsd /mnt/extsd auto /devices/virtual/block/mmcblk0p13

Next I converted the extracted kernel from the nandc file to be uboot compatible, again in the download zip there is a pre-built file (uImage). If your interested, I used the following command to convert the kernel:

mkimage -A ARM -C none -T kernel -O linux -a 40008000 -e 40008000 -d nandc-kernel uImage

Copy the uImage file to first partition on the SD card (this is bootloader FAT16 partition which is empty ). Also copy the uboot config files uEnv.txt and boot.scr to the first partition.

Finally I copied the Hackberry uboot files sunxi-spl.bin and u-boot.bin to the SD card to make it bootable. This is the reason for the leaving 16MB free at the start of the SD card.

sudo dd if=sunxi-spl.bin of=/dev/[drive] bs=1024 seek=8
sudo dd if=u-boot.bin of=/dev/[drive] bs=1024 seek=32
sudo sync

I suggest you delete everything of the data partition (eg /dev/sdc6), this will ensure the correct device partitions are found and recorded on the first boot. It would be prudent to hook up a serial console to the Hackberry to monitor boot progress in case of failures. Insert the SD card into the Hackberry and power up.

Once you have Android booting, turn off media scanning for the SD card. This option is in Setting->Storage>"Enable media scanning on SD".

If want to try deploy another kernel (assuming the kernel and modules are compatible with the Android image) then:

Copy the newly built uImage file to the first partition of the SD card.
Copy the modules to the /vendor/modules on the system partition of the SD card.

Having heard about Razor-qt, I thought I would give it a go on the Hackberry. Razor-qt is a light-weight desktop built for simplicity and speed. It is also intended to target 'weak machines' therefore I was hoping it would perform well on the Hackberry giving that we still lack full hardware acceleration.

To start with I reused my XBMC image which is basically a Ubuntu 12.10 install complemented with a 3.0.42+ kernel. You can remove the xbmc install by removing the /allwinner (ie rm -rf /allwinner).

I couldn't find a pre-compiled armhf package of raxor-qt therefore I built from scratch (using root user) following the build instructions here as a guide. Fortunately the xbmc image already includes most of the build tools for compilation.

Download the latest release and untar to a directory (eg src/razor) :

mkdir src; cd src; mkdir razor;

wget https://github.com/downloads/Razor-qt/razor-qt/razorqt-0.5.1.tar.bz2

tar xvf razorqt-0.5.1.tar.bz2 razorqt-0.5.1

cd ..

mkdir build

Before building get some additional packages for building:

apt-get install qt4-dev-tools qt4-designer

apt-get install libmagic-dev

Now build (this takes a bit of time) and install

cd build

cmake -DCMAKE_INSTALL_PREFIX=/usr/local ../razorqt-0.5.1

make

make install

Once built successfully we need to replace the existing window manager fluxbox with openbox the default for razor-qt.

apt-get remove fluxbox

apt-get clean

apt-get install openbox

Now we create a simple startup script to invoke razor-qt.

echo 'exec razor-session -w openbox' > /root/.xinitrc_razor

I suggest setting the CPU governor profile to performance:

cpufreq-set -g performance

To start razor-qt from the command line:

cd /root

xinit ~/.xinitrc_razor -- :1

The basic desktop has minimal applications because the XBMC image has no defaults application installed (eg browser, file manager, text editor, etc ..) however these is can be easily installed. You would also need to customise the image to your requirements ie wifi/ethernet etc. Also further work is require to auto-start razort-qt and use for non-root users.

Although the desktop experience is primitive I found it to be more responsive than the Linaro image although my main use has been for code development/compilation on the Hackberry, requiring multiple open command shells.

I also compiled the mesa-demo library to stress the windowing system/cpu along with 'openssl speed' to see how responsive the GUI would remain under load. Below is a another badly made video to demonstrate how it performs.

Budget CC1110/2430/2510 programmer/debugger

Nano SL5 Alarm Panel

Friedland Alarm Serial Ouput

Raspberry PI first impressions

Raspberry PI meets Nano Alarm Panel

HackBerry A10 board

Hackberry A10 available to buy from here .

Hackberry A10 update 1

Hackberry A10 available to buy from here .

Hackberry A10 First attempt to boot Ubuntu 12.04 & Puppy Linux

Hackberry A10 Bootloader

Hackberry A10 - Wireless Access Point

Hackberry A10 - Home Alarm Interfacing

Hackberry A10 - Debian Wheezy (Headless)

Hackberry A10 - Linaro 12.06 (Desktop)

1. Use download my pre-built image

2. Build from scratch as below:

Now to test it boots:

Hackberry A10 - 3G Modem Support

Hackberry A10 - Compiling a kernel (armhfs)

Hackberry A10 - Java benchmarks

Hackberry A10 - Extra USB Ports

Hackberry A10 - XBMC

Hackberry A10 - Booting Android from an SD Card

Hackberry A10 : Ubuntu 12.10 with Razor-qt