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.

 

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.

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

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.

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.

Raspberry PI first impressions

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!

Friedland Alarm Serial Ouput

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.