!!! Mediawiki has been upgraded !!!
Slack integration has been disabled for now due to an incompatibility.
If you want to testdrive the new skin (Tweeki), make sure your language settings are set to 'en - English' in your preferences!

Domus

From Brixel - Hackerspace Hasselt
Revision as of 10:45, 23 September 2014 by Johan (talk | contribs) (Boot0)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search


Project: Domus
350x350px
Description: Home Automation with MisterHouse and a CubieTruck.
Status: New
Participants: Johan
Edit tags: Domus


Why CubieTruck?

It needs to be low power, because it is always on. I also want to run a "real" server O.S. in order to have greater flexibility.

Below are some features CubieTruck has over other ARM based platforms:

  • 2G RAM, to run enough applications.
  • Dual Core Cortex-A7 (912MHz) to have relatively decent speed.
  • 8G on-board NAND flash. (No SD card required.)
  • SATA connectivity to easily add extra storage that is not dead slow or unstable.
  • 1Gb/s Ethernet and WIFI + BlueTooth on board.
  • Native RTC module in order to have good timekeeping.
  • Battery connector on board, in order to keep the device running during power outages. (It will also charge the battery.)

See http://cubieboard.org/ for more information about CubieTruck, also known as Cubieboard3.

Why MisterHouse?

Because I like it. ;-)
It is a framework written in Perl that has all that is needed included. You only need to write the logic and/or expansions.

I believe a home automation system needs to be on the background, doing what it is supposed to do. The system needs to be autonomous, resulting in Home Automation. Most other available software tends to focus on interaction/interfacing. This is Home Control, not Home Automation.

See http://misterhouse.wikispaces.com/ for more information about MisterHouse.
The sofware is available on https://github.com/hollie/misterhouse

CubieTruck Installation

Boot

Boot0

CubieTruck loads boot0 for booting. The boot sequence is as follows:

  1. Boot into FEL if "bsp"-pin is LOW.
  2. Load the first 4k of data from SD-slot 0 if SD card is present and check the magic string. Load whole boot0 if OK, boot into FEL if not OK.
  3. Same, but for internal NAND flash.
  4. Same, but for SD-slot 1 if the hardware is equiped with this second SD slot

This means it is possible to have a production system on NAND flash, and try experimental things on SD card with very little worries of breaking too much. After the experimental work on SD-card is found stable, it can be copied over to NAND flash.

As the boot sequence loads the first 4k of data from the device, it also means this data resides before the partition table and is not accessible through a filesystem.

u-boot

Boot0 will then normally call something like u-boot to further boot the device and most likely u-boot will then boot the Linux kernel.

Kernel

The default kernel is rather old (3.4.x), is heavily customized, and lacks many of the newer features.
The good news is there is work underway to use the mainline (Vanilla) Linux kernel on CubbieTruck.