Sunday, 30 September 2012

Hackberry A10 - Home Alarm Interfacing

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.



Sunday, 23 September 2012

Hackberry A10 - Wireless Access Point

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.

Friday, 10 August 2012

Hackberry A10 Bootloader

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.

 

Saturday, 4 August 2012

Hackberry A10 First attempt to boot Ubuntu 12.04 & Puppy Linux

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.


Wednesday, 1 August 2012

Hackberry A10 update 1


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







Monday, 16 July 2012

HackBerry A10 board

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.

Monday, 4 June 2012

Raspberry PI meets Nano Alarm Panel

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.