Bticino F454

This page shall be a container for various pieces of information about Bticion's F454. Most of the information is - for now - derived from just poking around on the device with SSH. So, due to this and in general: of course certain details can be unsure or not accurate, because something has been overlooked.

The F454 is a typical embedded system using a SoC and running a Linux-based system.

Hardware

The F454 is based on TI's (Texas Instruments) DaVinci DM365 SoC, from 2009. The Wikipedia page Texas Instruments DaVinci can be used as a first overview.

CPU

The SoC does include, among many peripherals, an ARM processor:

• family: ARM9E
• architecture: ARMv5TEJ
• core: ARM926EJ-S

Apparently DM365 SoCs can run with 216 MHz, 270 MHz or 300 MHz.

A look at Linux' /proc/cpuinfo confirms:

root@basi:~# cat /proc/cpuinfo 
Processor	: ARM926EJ-S rev 5 (v5l)
BogoMIPS	: 134.34
Features	: swp half thumb fastmult edsp java 
CPU implementer	: 0x41
CPU architecture: 5TEJ
CPU variant	: 0x0
CPU part	: 0x926
CPU revision	: 5

Hardware	: BTicino BASI board
Revision	: 0000
Serial		: 0000000000000000

The system includes a device called bt_nexmed_hwmon.0. It is registered as a Linux hardware monitoring device and provides further information.

root@basi:~# cd /sys/devices/platform/bt_nexmed_hwmon.0
root@basi:/sys/devices/platform/bt_nexmed_hwmon.0# ls in* temp*
in1_input    in1_label    in2_input    in2_label    in4_input
in4_label    in5_input    in5_label    temp1_input  temp1_label

input	label	typical value	comment
in1	Hw version	0
in2	board identification	BASI BOARD
in4	cpu speed	270MHz
in5	board configuration	4	unknown - what does it mean?
temp1	Temperature	38	most likely in celcius?

Memory

/proc/meminfo lets us assume the SoC is equipped with most likely >102 MB of RAM:

root@basi:/sys/devices/virtual/gpio# cat /proc/meminfo | head -n 1
MemTotal:         103968 kB

Obviously there is no such thing as a 103968 kiB RAM chip. A kernel commandline found within the U-Boot environment suggests that there are 128MiB of RAM. The assumption is that the rest of the RAM, up to 128MiB, is associated with the DM365's HDVICP1 co-processor - instead of being under Linux' control.

The HDVICP1 is a 720p H264 encoder and decoder included in the DaVinci DM365 SoC. Altogether the DM365 SoC seems to be the most equipped DaVinci SoCs of it's series and time (2008/2009).

Question: Why DM365 - why does the F454 need this 720p en/decoding capability. Wouldn't a DM355 also do it? Related to video door entry systems?

Serial interfaces

The DM365 SoC includes two on-chip UARTs [1], which are both more or less 8250/16550A compatible ones. For the F454 bticino added a third, external UART, also 8250/16550A compatible, which is apparently attached to the Asynchronous External Memory Interface of the DM365.

Within Linux they are represented by ttySx character device nodes:

root@basi:~# ls -l /dev/ttyS*
crw-r-----    1 root     root       4,  64 Feb 21 16:35 /dev/ttyS0
crw-r-----    1 root     root       4,  65 Feb 22 10:55 /dev/ttyS1
crw-r-----    1 root     root       4,  66 Feb 22 10:55 /dev/ttyS2
crw-r-----    1 root     root     204,   5 Nov  8  2012 /dev/ttySA0

Note that the device node ttySA0 (major 204, minor 5) does not really exist. It seems to be a leftover and is not needed/used.

The following table shows how these UARTs are used:

UART	Linux device node	usage	settings
DM365 UART0	/dev/ttyS0	BUBL, U-Boot and Linux system console	115200 baud / no parity / 8 data bits / 1 stop bit
DM365 UART1	/dev/ttyS1	SCS AV bus communication via a PIC microcontroller	38400 baud / no parity / 8 data bits / 1 stop bit
external UART	/dev/ttyS2	SCS AI bus communication via a (second) PIC microcontroller	38400 baud / no parity / 8 data bits / 1 stop bit

The settings can be verified by, for example:

root@basi:~# stty -a -F /dev/ttyS1
speed 38400 baud; rows 24; columns 80;
intr = <undef>; quit = <undef>; erase = <undef>; kill = <undef>; eof = ^D; eol = <undef>; eol2 = <undef>; start = <undef>; stop = <undef>;
susp = <undef>; rprnt = <undef>; werase = <undef>; lnext = <undef>; flush = <undef>; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread clocal -crtscts
-ignbrk -brkint ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl ixon ixoff -iuclc -ixany -imaxbel
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke

Accessibility

Bticino's F454 Technial Sheet documents there is a Serial connector RS232 behind the hatch of the F454's case, left of the 3 LEDs.

It is a 5 pin male connector of an, at least to your author, unknown type (TODO). In general it seems more than likely that this connector is going to UART0, the system console. However it remains unclear, which pins are what (3 needed at least: GND, TX, RX) and what the voltage levels are (TODO). Of course, the designation RS232 is a pretty clear statement and suggests that the PCB includes a MAX232 or similar and thus it could be directly connected to a PCs serial port/USB-to-serial.

TODO: try it out, determine pins

Storage

eMMC

The F454 includes a eMMC as non-volatile storage. It's size is 1,872 MiB (sector size: 512 byte) and is divided into essentially 6 paritions, using MBR style:

partition	start sector	size in sectors / in KiB	usage
1	1	4159 / 2079.5 KiB	U-Boot binary at 0x00e00, size 0x028270 U-Boot environment at offset 0x5ee00, size 0x01000
2	4160	20544 / 10,272 KiB	ext3, comprises recovery Linux kernel uImage
3	24704	409664 / 204,832 KiB	ext3, recovery root filesystem, mounted read-only
5	434369	20543 / 10,271.5 KiB	ext3, comprises normal Linux kernel uImage
6	454913	409663 / 204,831.5 KiB	ext3, normal root filesystem, mounted read-only
7	864592	2969264 / 1,484,632 KiB	ext3, mounted on /home/bticino/cfg/extra, mounted read-write

Note that the U-Boot binary is at absolute offset 0x200 + 0xe00 = 0x1000.

EEPROM

For booting the F454 there is most likely an EEPROM. It is attached to interface SPI0 of the DM365. The used Linux kernel source suggests that it as a at25640, 64K bits in size. However that seems to be a bit small. More likely is something like 256K (TODO: see section software).

After power-on the DM365's ARM ROM boot loader (RBL) searches for its user boot loader (UBL). It does so via a pre-determined interface. The current assumption is that this interface is SPI. Other possibilities are for example NAND, MMC/SD, UART, ...

In case of the F454 the only other possibility would be MMC, but on the eMMC there does not seem to be the correct magic number (0xA1ACEDxx) within the first 24 blocks. So it has to be an SPI EEPROM - for booting.

Further information

The following talk by Raffaele Recalcati on FOSDEM 2011 provides some more details: DaVinci dm365 for home automation Video Slides (English). However it does not explicitly mention the F454. It includes background information, development history and even block diagrams. From the same author there is a presentation from 2012 called Linux in Bticino (Italian). It apparently includes more of Bticino's history in home automation and even something on the userspace application stack.

TODO: more

Software

Tool Chain

For its DaVinci SoCs, to compile Linux kernels, TI recommends [2] CodeSourcery's GNU Toolchain for ARM Processors, version 2009q1-203, which can be downloaded as a tar archive (or a self-extracting archive, bigger not recommended).

TI's Arago Project also refers to that specific tool chain version [3] - to be used not only for kernel, but to compile everything - from bootloader to userspace applications.

This tool chain can also be found, pre-installed, in bticino's F454/003598 SDK. The SDK is a Ubuntu 12.04 Live DVD, with some non-standard programs like this tool chain pre-installed.

Boot loader

ARM ROM boot loader - RBL

After power-on the DM365's ARM processor starts with executing the ARM ROM boot loader (RBL), which resides in an on-chip ROM mapped to 0x08000 / 0x18000 (Instruction/Data; size: 16KiB). The RBL searches for a user boot loader (UBL). In case of the F454 the current assumption is that it does so via DM365's SPI0 interface - on an attached SPI EEPROM.

The RBL expects to find a certain magic number in the first 32 bit of the EEPROM. This number has be either 0xa1aced00 (24 bit addressing) or 0xa1aced01 (16 bit addressing).

The magic number must be followed by 20 bytes of additional information, like UBL executable entry point, size of the UBL, start and load addresses, flags ... TI's DM36x User's Guide ARM Subsystem has all the details, chapter 11.2.5, page 188.

After having found this piece of information, the RBL acts accordingly: loads the UBL into the ARM's on-chip TCM RAM0 and RAM1 (2x 16 KiB, at address space offset 0x0000 and 0x4000 respectively) and jumps to the specified entry point.

User boot loader - UBL

The user boot loader (UBL) used by the F454 is called BUBL and its source code can be found on gitorious.org in repository called medium_platform/bubl.

As of this writing, the latest commit has the hash 90833fe . Apparently this is exactly the version used in the F454, since this commit hash can be found in 2 places on the F454 - at runtime (!):

• in the ARM TCM RAM0 and RAM1 (offset 0x5dd4): <BUBL 2011.0-rc1-g90833fe>
• in the U-Boot environment on eMMC at absolute offset 0x5f000: baselineloader_version=BUBL 2011.0-rc1-g90833fe

This also gives an idea what the leading B could stands for - apparently baseline - whatever that means in this case ...

BUBL completes the following steps:

• setup PLL(s)
• setup timer(s)
• setup ADC
• setup DDR memory controller
• output (using UART0) various pieces of information, determined via previously setup ADC (partially info the device bt_nexmed_hwmon.0 under Linux provides, too)
  • board type (BASI)
  • hardware version (???)
  • boot device (eMMC)
  • CPU frequency (270)
  • RAM size (??? MB)
  • ...

After these initial steps, BUBL continues with loading a binary blob from either NAND or eMMC into RAM. BUBL expects this binary blob to be a U-Boot binary.

• if ADC value 4 says to boot from NAND (NOT the case on F454!)
  • setup NAND interface
  • read U-Boot from NAND (offset?, size?), into RAM at offset 0x81100000
• else
  • setup MMC/SD interface
  • read U-Boot from eMMC at offset 0x1000, size 256 KiB, into RAM at offset 0x81080000

The binary blob loaded into RAM is checked for validity - if it is really a U-Boot binary (doubleword at offset 0x3c has to be 0xdeadbeef).

If it is not U-Boot or if there is the character s received on UART0, BUBL discards any loaded binary blob and expects to receive a S-record file from UART0 instead. BUBL writes the received S-record file, translated to binary, into RAM at the offset determined from the S-record file.

The last step is to either jump

• to 0x81100000, in case of U-Boot from NAND OR
• to 0x81080000, in case of U-Boot from eMMC OR
• to the address determined from the receive S-record file.

U-Boot

The F454's user boot loader, BUBL, expects to load a U-Boot binary - via MMC/SD interface. It is expected to be 4 KiB into the F454's eMMC (offset 0x1000) and is assumed to be maximally 256 KiB in size.

Origin

A look at the U-Boot environment (variable ver), and also at the readable ASCII strings of the U-Boot binary, tells us what version of U-Boot is used:

root@basi:~# fw_printenv | grep ^ver= | sed 's#^ver=##'
U-Boot 2010.12-rc2-3ed2d264ae41bbc05f961a8aececdd636cdb1582 (Jul 23 2012 - 11:40:09)

root@basi:~# dd if=/dev/mmcblk0p1 bs=$((0xe00 + 0)) skip=1 count=$(((256 * 1024) / 0xe00)) 2>/dev/null | strings | grep -e 'U-Boot '
U-Boot 2010.12-rc2-3ed2d264ae41bbc05f961a8aececdd636cdb1582 (Jul 23 2012 - 11:40:09)
ubootver=U-Boot 2010.12-rc2-3ed2d264ae41bbc05f961a8aececdd636cdb1582

So it is obviously based on release candidate 2 for U-Boot 2010.12 . The Git commit hash, which follows -rc2- should tell us about the exact source code version.

bticino published the source code on their MyOpenCommunity site on GitHub. It resides in a Git repository called http://github.com/MyOpenCommunity/u-boot-davinci-medium . As of this writing it's master branch of this repository is ahead by 3 newer commits. A link to the above mentioned commit hash is: 3ed2d264ae41bbc05f961a8aececdd636cdb1582.

It turns out that this copy of U-Boot has been derived from:

• arago-project.org U-Boot for DaVinci, tag DEV.DavinviBSP.03.01.01.38 (commit 6ebeaa9)
• denx.de U-Boot, some commits after tag v2010.12-rc2 (commit f8689b)

Note that arago-project.org does also have a tag DEV.DavinviBSP.03.01.01.39, which is currently equivalent to where the branch r39 points to. And more interesting: this tag is just one single commit further than where tag DEV.DavinviBSP.03.01.01.38 points to.

To avoid confusion: The MyOpenCommunity also has a repository called u-boot-davinci-medium-v2. This is newer version, based on denx.de's U-Boot (commit d41b3cc) - somewhere between versions v2013.01-rc2 and v2013.01-rc1. So later shipped F454 devices might have a U-Boot binary installed which is based on this newer source code base.

Operation

TODO

Operating System

Kernel

Origin

A look at Linux' /proc/version and /boot, while running F454 firmware version 1.00.37, suggest:

root@basi:~# cat /proc/version 
Linux version 2.6.32.17-davinci1-8ed3c294c0a661d818ffab0b94c381289740d429 (bticino@medium1) (gcc version 4.3.3 (Sourcery G++ Lite 2009q1-203) ) #1 PREEMPT Thu Nov 8 17:02:20 CET 2012
root@basi:~# ls -l /boot/
lrwxrwxrwx    1 root     root           66 Nov  8  2012 uImage -> uImage-2.6.32.17-davinci1-8ed3c294c0a661d818ffab0b94c381289740d429

So, the used Linux kernel is apparently based on version 2.6.32.17 within Git repository http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git .

Furthermore, when we look at the kernel image file, called uImage, which get's loaded by U-Boot on startup:

$ unzip Firmware_F454_vers010037.zip
Archive:  Firmware_F454_vers010037.zip
  inflating: F454_010037.fwz
$ unzip -P F454  F454_010037.fwz
Archive:  F454_010037.fwz
  inflating: btweb_only.ext3.gz      
  inflating: btweb_only_recovery.ext3.gz  
  inflating: fwz.xml                 
  inflating: uImage
$ mkimage -l uImage 
Image Name:   Arago/2.6.32.17-psp03.01.01.39/b
Created:      Thu Nov  8 17:02:33 2012
Image Type:   ARM Linux Kernel Image (uncompressed)
Data Size:    1720032 Bytes = 1679.72 kB = 1.64 MB
Load Address: 80008000
Entry Point:  80008000

We recognize 2 important hints within the Image Name of the uImage: Arago and the version amendment psp03.01.01.39. Together with the amendment -davinci1 seen within /proc/version, these 2 hints make a very strong suggestion that the used Linux kernel version is based on one managed by TI as part the Arago project: tag DEV.DaVinciPSP.03.01.01.39 within Git repository git://arago-project.org/git/projects/linux-davinci.git .

All these assumption about on what version the used kernel is based on become certain facts after finding one of bticino's public Git repositories on GitHub: http://github.com/MyOpenCommunity/linux-davinci-medium . It comprises the commit with the hash 8ed3c294c0a661d818ffab0b94c381289740d429, which occurs in /proc/version as an amendment to the kernel version.

Newer versions of the firmware apparently use slightly newer kernel versions/commits, which can also be found in the mentioned repository. Commits of firmware version 1.00.xx kernels are part of a branch called f454_1. Commits of firmware version 2.00.xx kernels can be found on the basi branch.

firmware version	compile stamp	kernel version	commit hash
v1.00.34	Thu Nov 8 17:02:20 CET 2012	v2.6.32.17-davinci1	8ed3c294c0a661d818ffab0b94c381289740d429
v1.00.37	Thu Nov 8 17:02:20 CET 2012	v2.6.32.17-davinci1	8ed3c294c0a661d818ffab0b94c381289740d429
v1.00.45	Fri Jan 17 17:16:09 CET 2014	v2.6.32.17-davinci1	59f7438a4e85d0a2b1b985a65500a9f05366f6ce
v1.00.51	Thu Sep 4 18:03:59 CEST 2014	v2.6.32.17-davinci1	f56c4d42a889cb71bd92d101e9e2b0e847ca1603
v2.00.46	Wed Oct 28 10:51:58 CET 2015	v2.6.32.17-davinci1	c44221b9cd7e82d5ec494320685310d138f4dd07
v2.00.48	Thu Jan 7 18:34:50 CET 2016	v2.6.32.17-davinci1	c44221b9cd7e82d5ec494320685310d138f4dd07
v2.00.50	Thu Feb 11 10:07:14 CET 2016	v2.6.32.17-davinci1	c44221b9cd7e82d5ec494320685310d138f4dd07

Configuration

Apparently all kernels include the set of configuration options used to compile them (CONFIG_IKCONFIG=y), because all kernel files have embedded gzip data blobs. To extract such a configuration file from a uImage like the ones found in firmware updates:

# extract kernel image, (pure binary, arch/arm/boot/Image)
$ ZIO=$(binwalk uImage | \
	grep -v -e '^$' -e '^DECIMAL' -e '^-\+' | \
	grep -e 'gzip compressed data' | \
	awk '{ print $1 }'); \
	dd if=uImage bs=$ZIO skip=1 | gunzip >Image
# extract embedded config file
$ CGZO=$(binwalk Image | \
	grep -v -e '^$' -e '^DECIMAL' -e '^-\+' | \
	grep -e 'gzip compressed data' | \
	awk '{ print $1 }');
	dd if=Image bs=$CGZO skip=1 | gunzip >config

It turns out that all three different versions known so far do have exactly the same configuration. The only differences is the typical timestamp which is placed at the beginning of Linux kernel configuration files.

firmware version	time stamp	md5sum
v1.00.34	Thu Nov 8 17:01:23 2012	76526190d9603899b4cf6d947d9ed39c
v1.00.37	Thu Nov 8 17:01:23 2012	76526190d9603899b4cf6d947d9ed39c
v1.00.45	Fri Jan 17 17:15:22 2014	6973e72623f206073f9359035d076ae8
v1.00.51	Thu Sep 4 18:03:13 2014	3e3aaf37a4158eeb1e92417aa51bc16b

The following list shows some of the enabled features - besides the expected ones (support for the Davinci SoC and it's peripherals). Features, which might be surprising to see and/or which are most likely not really used by the current firmware:

• core
  • Tickless System
  • Suspend to RAM and standby
• network
  • IPv4
    • in-kernel DHCP support
    • IPsec: transport, tunnel and BEET mode
  • IPv6 (module)
• drivers
  • loopback device (module)
  • TUN/TAP device (module)
  • PPP with async/sync serial support and deflate compression (modules)
  • network console logging
• filesystems
  • Dnotify and Inotify support
  • Kernel automounter v4 (module)
  • FAT
  • NFS v2 and v3
  • NFS v2 and v3 server (module)
  • SMB (module)

On an F454 running firmware version v1.00.37, the following modules are loaded:

root@basi:~# lsmod
Module                  Size  Used by
ipv6                  247137  16 
g_ether                27235  0 
musb_hdrc              28058  1 g_ether
dm365mmap               1955  0 
edmak                  12651  0 
irqk                    6411  0 
cmemk                  22327  0

Of the above listed features, which are build as modules, just kernel level support for IPv6 is actually loaded. All other loaded modules are peripheral drivers.

TODO: more

Applications

TODO