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?

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

TODO

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 most likely resides in an address space starting at 0x00018000. 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 interface SPI0 - on an attached SPI EEPROM.

The RBL specifically searches for a certain magic number (32 bit), which is 0xa1acedxx. At this point in time it remains a little bit unclear if this number has to be at offset 0x0 of the EEPROM (most likely) or if it can reside within a certain range of bytes/pages/whatever.

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 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 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

TODO

Operating System

TODO

Applications

TODO