Bticino F454

From piMyHome Project
Revision as of 22:14, 17 February 2015 by Joft (talk | contribs) (→‎Kernel: Add table of kernel version seen in different firmware versions.)
Jump to navigation Jump to search

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

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.

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:

U-Boot 2010.12-rc2-3ed2d264ae41bbc05f961a8aececdd636cdb1582 (Jul 23 2012 - 11:40:09)

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.

Unfortunately, as of this writing, your author hasn't been able to find any public source repository, which does comprise a commit with this hash. However there is the very strong assumption that the source code the F454's U-Boot binary was built from is at least based on this gitorious.org repository: medium_platform/u-boot .

It turns out that this repository's master branch (commit f319d40) has been derived from:

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.

TODO: more

Operating System

Kernel

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 gitorious.org: http://gitorious.org/medium_platform/linux . 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. However the commit hashes of the newer versions were not yet found in any public repository.

firmware version kernel version commit hash
v1.00.34 v2.6.32.17-davinci1 8ed3c294c0a661d818ffab0b94c381289740d429
v1.00.37 v2.6.32.17-davinci1 8ed3c294c0a661d818ffab0b94c381289740d429
v1.00.45 v2.6.32.17-davinci1 59f7438a4e85d0a2b1b985a65500a9f05366f6ce
v1.00.51 v2.6.32.17-davinci1 f56c4d42a889cb71bd92d101e9e2b0e847ca1603

TODO: more

Applications

TODO

Retrieved from "http://www.pimyhome.org/wiki/index.php?title=Bticino_F454&oldid=348"