piMyHome Project - User contributions [en]

Bticino F454

2016-10-04T18:42:16Z

Joft: Add info about toolchains used for firmware v2.00.xx .

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 [http://www.ti.com/product/tms320dm365 DM365] SoC, from 2009. The Wikipedia page [http://en.wikipedia.org/wiki/Texas_Instruments_DaVinci Texas Instruments DaVinci] can be used as a first overview.

== CPU ==

The SoC does include, among many peripherals, an [http://en.wikipedia.org/wiki/List_of_ARM_microarchitectures ARM processor]:

* family: [http://en.wikipedia.org/wiki/ARM9E 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:
<source lang="bash">
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
</source>

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

<source lang="bash">
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
</source>

{| class="wikitable"
! style="text-align:left;"| input
! style="text-align:left;"| label
! style="text-align:left;"| typical value
! style="text-align:left;"| 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:
<source lang="bash">
root@basi:/sys/devices/virtual/gpio# cat /proc/meminfo | head -n 1
MemTotal: 103968 kB
</source>

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 [http://www.ti.com/lit/ug/sprufh2/sprufh2.pdf], 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 [http://www.ti.com/lit/ug/sprufi1c/sprufi1c.pdf Asynchronous External Memory Interface] of the DM365.

Within Linux they are represented by ''ttySx'' character device nodes:
<source lang="bash">
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
</source>
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:
{| class="wikitable"
! style="text-align:left;"| UART
! style="text-align:left;"| Linux device node
! style="text-align:left;"| usage
! style="text-align:left;"| 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:
<source lang="bash">
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
</source>

=== Accessibility ===

Bticino's F454 [http://www.homesystems-legrandgroup.com/technicalDocuments/type5/MQ00519-b-EN.pdf Technial Sheet] documents there is a ''Serial connector RS232'' behind the hatch of the F454's case, left of the 3 LEDs. It is the connector with the white case, right below the Mini-USB connector.

The 5 pin male connector is of an, at least to your author, unknown type. One of the plugs tried so far is a ''TODO'', but the notches at the sides do not match. However the pin spacing and the position of the pin row relative to the bottom side do match. So, a pocket knife makes the plug fit.

Starting at the left hand side, the first 4 pins show a voltage of 3.3V compared to the right most pin, when using simple multimeter. So, this ''Serial connector RS232'' '''CANNOT''' be a standard [https://en.wikipedia.org/wiki/RS-232 RS-232] interface. It turns out that it is a 3.3V tolerant [https://en.wikipedia.org/wiki/Universal_asynchronous_receiver/transmitter UART] interface. And that is what one would expect of such a SoC like the DM365, anyway.

The purpose of the 5 pins is as follows. Pin numbering starts at the right hand side (LEDs) with 0.
{| class="wikitable"
! style="text-align:left;"| pin
! style="text-align:left;"| purpose
|-
|0
|GND
|-
|1
|UART RX
|-
|2
|UART TX
|-
|3
|''unknown''
|-
|4
|''unknown''
|}

Connecting one of these UART-to-USB dongles for 3.3V and watching what is send by the F454 during startup, confirms the assumption that this UART interface is indeed wired to the DM365's UART0 - /dev/ttyS0 from the Linux kernel's point of view. It is run with 115200 baud, 8 data bits and 1 stop bit.

== 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 [http://en.wikipedia.org/wiki/Master_boot_record MBR] style:

{| class="wikitable"
! style="text-align:left;"| partition
! style="text-align:left;"| start sector
! style="text-align:left;"| size in sectors / in KiB
! style="text-align:left;"| 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 [http://it.linkedin.com/pub/raffaele-recalcati/b/7b/3a9 Raffaele Recalcati] on [https://archive.fosdem.org/2011 FOSDEM 2011] provides some more details: [https://archive.fosdem.org/2011/schedule/event/davinci.html DaVinci dm365 for home automation] [http://free-electrons.com/pub/video/2011/fosdem/fosdem2011-recalcati-home-automation.webm Video] [http://elinux.org/images/1/1f/Basi_and_dingo.pdf 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 [http://www.gl-como.it/wp-content/uploads/2012/09/Linux_in_Bticino_LinuxDay2012.pdf 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 [http://processors.wiki.ti.com/index.php/DaVinci_GIT_Linux_Kernel#Overview] CodeSourcery's ''GNU Toolchain for ARM Processors'', version ''2009q1-203'', which can be downloaded as a [http://www.codesourcery.com/sgpp/lite/arm/portal/package4573/public/arm-none-linux-gnueabi/arm-2009q1-203-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2 tar archive] (or a [http://www.codesourcery.com/sgpp/lite/arm/portal/package4573/public/arm-none-linux-gnueabi/arm-2009q1-203-arm-none-linux-gnueabi.bin self-extracting archive], ''bigger not recommended'').

TI's [http://arago-project.org Arago Project] also refers to that specific tool chain version [http://arago-project.org/wiki/index.php/Getting_CodeSourcery_Toolchain] - to be used not only for kernel, but to compile everything - from bootloader to userspace applications.

=== Firmware v1.00.xx ===

These old firmware versions seem to be indeed compiled using the toolchain mentioned above. For example, within the Linux kernel binaries this string can be found:

<pre>gcc version 4.3.3 (Sourcery G++ Lite 2009q1-203)</pre>

Furthermore this toolchain can also be found, pre-installed, in bticino's [http://www.myopen-legrandgroup.com/devices/gateways/m/f454_-_003598/45317.aspx F454/003598 SDK]. The SDK is a Ubuntu 12.04 Live DVD, with some non-standard programs like this toolchain pre-installed.

=== Firmware v2.00.xxx ===

Current firmware versions are obviously compiled with a different toolchain. Again, from Linux kernel binaries:

<pre>gcc version 4.8.2 (GCC)</pre>

When looking through the firmware's root filesystem, the following string can be found in the /etc/lsb-release file:

<pre>Poky (Yocto Project Reference Distro) 1.6.2</pre>

This suggests that the root filesystem is build using the [https://www.yoctoproject.org/ Yocto Project] build system and is derived from its ''reference distribution'' [https://www.yoctoproject.org/tools-resources/projects/poky Poky], version 1.6.2 . This version does actually include GCC v4.8.2 .

Usually the toolchain, including GCC, is compiled as part of the build process of the Yocto Project's build system. That said, the Yocto Project usually offers pre-built toolchains for download as self-extracting archives: [http://downloads.yoctoproject.org/releases/yocto/yocto-1.6.2/toolchain/x86_64/poky-eglibc-x86_64-core-image-sato-armv5te-toolchain-1.6.2.sh poky-eglibc-x86_64-core-image-sato-armv5te-toolchain-1.6.2.sh].

== 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 [http://www.ti.com/lit/pdf/sprufg5 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 [https://gitorious.org/ gitorious.org] in repository called [https://gitorious.org/medium_platform/bubl/source/90833fe26b0c5a833054e939909fc887c94561d9: medium_platform/bubl].

As of this writing, the latest commit has the hash [https://gitorious.org/medium_platform/bubl/commit/90833fe26b0c5a833054e939909fc887c94561d9 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 [https://gitorious.org/medium_platform/bubl/source/90833fe26b0c5a833054e939909fc887c94561d9:main.c#L109 steps]:

* setup PLL(s)
* setup timer(s)
* setup ADC
* setup DDR memory controller
* output (using UART0) various [https://gitorious.org/medium_platform/bubl/source/90833fe26b0c5a833054e939909fc887c94561d9:main.c#L44 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 [https://gitorious.org/medium_platform/bubl/source/90833fe26b0c5a833054e939909fc887c94561d9:main.c#L202 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 [https://gitorious.org/medium_platform/bubl/source/90833fe26b0c5a833054e939909fc887c94561d9:main.c#L270 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:

<source lang="bash">
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
</source>
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 [http://github.com/MyOpenCommunity MyOpenCommunity] site on [http://github.com 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: [http://github.com/MyOpenCommunity/u-boot-davinci-medium/commit/3ed2d264ae41bbc05f961a8aececdd636cdb1582 3ed2d264ae41bbc05f961a8aececdd636cdb1582].

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

* arago-project.org [http://arago-project.org/git/projects/?p=u-boot-davinci.git;a=summary U-Boot for DaVinci], tag [http://arago-project.org/git/projects/?p=u-boot-davinci.git;a=commit;h=6ebeaa9ef432217def1213e9cc611771d6412b1c DEV.DavinviBSP.03.01.01.38] (commit [http://arago-project.org/git/projects/?p=u-boot-davinci.git;a=commit;h=6ebeaa9ef432217def1213e9cc611771d6412b1c 6ebeaa9])
* denx.de [http://www.denx.de/wiki/U-Boot/WebHome U-Boot], some commits after tag [http://git.denx.de/?p=u-boot.git;a=commit;h=d0d2271f8c62e830ec65fb069b6d12dd708e3e2f v2010.12-rc2] (commit [http://git.denx.de/?p=u-boot.git;a=commit;h=f8689b f8689b])

Note that arago-project.org does also have a tag [http://arago-project.org/git/projects/?p=u-boot-davinci.git;a=commit;h=1af61f3b812b51f6f41ff37cd4a52ce6cfb21d7a 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 [http://github.com/MyOpenCommunity MyOpenCommunity] also has a repository called [http://github.com/MyOpenCommunity/u-boot-davinci-medium-v2 u-boot-davinci-medium-v2]. This is newer version, based on denx.de's U-Boot (commit [http://git.denx.de/?p=u-boot.git;a=commit;h=d41b3cc16fd97da23900f79e8fefdeedeebde8f6 d41b3cc]) - somewhere between versions [http://git.denx.de/?p=u-boot.git;a=commit;h=ebbf0d20aa85f623c49b7ed3349ebfea450c152d v2013.01-rc2] and [http://git.denx.de/?p=u-boot.git;a=commit;h=3ae7b240ad8c723d02aa79654220a07049b7ae4d 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:
<source lang="bash">
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
</source>

So, the used [http://kernel.org Linux] kernel is apparently based on [http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tag/?h=linux-2.6.32.y&id=v2.6.32.17 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:
<source lang="bash">
$ 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
</source>

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 [http://arago-project.org/ Arago project]: tag [http://arago-project.org/git/projects/?p=linux-davinci.git;a=commit;h=161e942bbb6e3603bccd1548865cfcce0910f1cc 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 [http://github.com GitHub]: http://github.com/MyOpenCommunity/linux-davinci-medium . It comprises the commit with the hash [http://github.com/MyOpenCommunity/linux-davinci-medium/commit/8ed3c294c0a661d818ffab0b94c381289740d429 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 [http://github.com/MyOpenCommunity/linux-davinci-medium repository]. Commits of firmware version 1.00.xx kernels are part of a branch called [https://github.com/MyOpenCommunity/linux-davinci-medium/tree/f454_1 f454_1]. Commits of firmware version 2.00.xx kernels can be found on the [https://github.com/MyOpenCommunity/linux-davinci-medium/tree/basi basi] branch.

{| class="wikitable"
! style="text-align:left;"| firmware version
! style="text-align:left;"| compile stamp
! style="text-align:left;"| kernel version
! style="text-align:left;"| commit hash
|-
|v1.00.34
|Thu Nov 8 17:02:20 CET 2012
|v2.6.32.17-davinci1
|[http://github.com/MyOpenCommunity/linux-davinci-medium/commit/8ed3c294c0a661d818ffab0b94c381289740d429 8ed3c294c0a661d818ffab0b94c381289740d429]
|-
|v1.00.37
|Thu Nov 8 17:02:20 CET 2012
|v2.6.32.17-davinci1
|[http://github.com/MyOpenCommunity/linux-davinci-medium/commit/8ed3c294c0a661d818ffab0b94c381289740d429 8ed3c294c0a661d818ffab0b94c381289740d429]
|-
|v1.00.45
|Fri Jan 17 17:16:09 CET 2014
|v2.6.32.17-davinci1
|[http://github.com/MyOpenCommunity/linux-davinci-medium/commit/59f7438a4e85d0a2b1b985a65500a9f05366f6ce 59f7438a4e85d0a2b1b985a65500a9f05366f6ce]
|-
|v1.00.51
|Thu Sep 4 18:03:59 CEST 2014
|v2.6.32.17-davinci1
|[http://github.com/MyOpenCommunity/linux-davinci-medium/commit/f56c4d42a889cb71bd92d101e9e2b0e847ca1603 f56c4d42a889cb71bd92d101e9e2b0e847ca1603]
|-
|v2.00.46
|Wed Oct 28 10:51:58 CET 2015
|v2.6.32.17-davinci1
|[http://github.com/MyOpenCommunity/linux-davinci-medium/commit/c44221b9cd7e82d5ec494320685310d138f4dd07 c44221b9cd7e82d5ec494320685310d138f4dd07]
|-
|v2.00.48
|Thu Jan 7 18:34:50 CET 2016
|v2.6.32.17-davinci1
|[http://github.com/MyOpenCommunity/linux-davinci-medium/commit/c44221b9cd7e82d5ec494320685310d138f4dd07 c44221b9cd7e82d5ec494320685310d138f4dd07]
|-
|v2.00.50
|Thu Feb 11 10:07:14 CET 2016
|v2.6.32.17-davinci1
|[http://github.com/MyOpenCommunity/linux-davinci-medium/commit/c44221b9cd7e82d5ec494320685310d138f4dd07 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:

<source lang="bash">
# 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
</source>

It turns out that all four different firmware v1.00.xx kernel versions known so far do have exactly the same configuration. The configuration of the firmware v2.00.xx kernel versions are different from the v1.00.xx ones. However within the v2.00.xx ones it is again the same configuration. The only differences within one family, say between v1.00.xx and v1.00.yy is the typical timestamp which is placed at the beginning of Linux kernel configuration files.

{| class="wikitable"
! style="text-align:left;"| firmware version
! style="text-align:left;"| time stamp
! style="text-align:left;"| 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
|-
|v2.00.46
|Wed Oct 28 10:49:54 2015
|20b4d997b4a307cb01d2a156f7551179
|-
|v2.00.48
|Thu Jan 7 18:33:28 2016
|eea14c82b90beb0bb3ba4ba2ccdb91d8
|-
|v2.00.50
|Thu Feb 11 10:05:41 2016
|0725aaa72d3d58dd0c89e4d4ee5a5458
|}

The following list shows some of the enabled features of both, v1.00.xx and v2.00.xx kernels '''''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)

The firmware v2.00.xx kernels do have additional features enabled. Again the list shows just the ones which might be surprising to see.

* network
** bridge (module)
*** stp (module)
*** netfilter, ebtables including DNAT, SNAT (modules)
** IPv4
*** netfilter, iptables including connection tracking, NAT, MASQ, STATE, ... (modules)
** IPv6
*** netfilter, iptables including connection tracking, STATE, ... (modules)
* filesystems
** devtmpfs

On an F454 running firmware version v1.00.37, the following modules are loaded:
<source lang="bash">
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
</source>

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

Bticino F454

2016-10-03T16:53:28Z

Joft: Add details on the serial connector.

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 [http://www.ti.com/product/tms320dm365 DM365] SoC, from 2009. The Wikipedia page [http://en.wikipedia.org/wiki/Texas_Instruments_DaVinci Texas Instruments DaVinci] can be used as a first overview.

== CPU ==

The SoC does include, among many peripherals, an [http://en.wikipedia.org/wiki/List_of_ARM_microarchitectures ARM processor]:

* family: [http://en.wikipedia.org/wiki/ARM9E 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:
<source lang="bash">
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
</source>

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

<source lang="bash">
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
</source>

{| class="wikitable"
! style="text-align:left;"| input
! style="text-align:left;"| label
! style="text-align:left;"| typical value
! style="text-align:left;"| 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:
<source lang="bash">
root@basi:/sys/devices/virtual/gpio# cat /proc/meminfo | head -n 1
MemTotal: 103968 kB
</source>

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 [http://www.ti.com/lit/ug/sprufh2/sprufh2.pdf], 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 [http://www.ti.com/lit/ug/sprufi1c/sprufi1c.pdf Asynchronous External Memory Interface] of the DM365.

Within Linux they are represented by ''ttySx'' character device nodes:
<source lang="bash">
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
</source>
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:
{| class="wikitable"
! style="text-align:left;"| UART
! style="text-align:left;"| Linux device node
! style="text-align:left;"| usage
! style="text-align:left;"| 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:
<source lang="bash">
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
</source>

=== Accessibility ===

Bticino's F454 [http://www.homesystems-legrandgroup.com/technicalDocuments/type5/MQ00519-b-EN.pdf Technial Sheet] documents there is a ''Serial connector RS232'' behind the hatch of the F454's case, left of the 3 LEDs. It is the connector with the white case, right below the Mini-USB connector.

The 5 pin male connector is of an, at least to your author, unknown type. One of the plugs tried so far is a ''TODO'', but the notches at the sides do not match. However the pin spacing and the position of the pin row relative to the bottom side do match. So, a pocket knife makes the plug fit.

Starting at the left hand side, the first 4 pins show a voltage of 3.3V compared to the right most pin, when using simple multimeter. So, this ''Serial connector RS232'' '''CANNOT''' be a standard [https://en.wikipedia.org/wiki/RS-232 RS-232] interface. It turns out that it is a 3.3V tolerant [https://en.wikipedia.org/wiki/Universal_asynchronous_receiver/transmitter UART] interface. And that is what one would expect of such a SoC like the DM365, anyway.

The purpose of the 5 pins is as follows. Pin numbering starts at the right hand side (LEDs) with 0.
{| class="wikitable"
! style="text-align:left;"| pin
! style="text-align:left;"| purpose
|-
|0
|GND
|-
|1
|UART RX
|-
|2
|UART TX
|-
|3
|''unknown''
|-
|4
|''unknown''
|}

Connecting one of these UART-to-USB dongles for 3.3V and watching what is send by the F454 during startup, confirms the assumption that this UART interface is indeed wired to the DM365's UART0 - /dev/ttyS0 from the Linux kernel's point of view. It is run with 115200 baud, 8 data bits and 1 stop bit.

== 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 [http://en.wikipedia.org/wiki/Master_boot_record MBR] style:

{| class="wikitable"
! style="text-align:left;"| partition
! style="text-align:left;"| start sector
! style="text-align:left;"| size in sectors / in KiB
! style="text-align:left;"| 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 [http://it.linkedin.com/pub/raffaele-recalcati/b/7b/3a9 Raffaele Recalcati] on [https://archive.fosdem.org/2011 FOSDEM 2011] provides some more details: [https://archive.fosdem.org/2011/schedule/event/davinci.html DaVinci dm365 for home automation] [http://free-electrons.com/pub/video/2011/fosdem/fosdem2011-recalcati-home-automation.webm Video] [http://elinux.org/images/1/1f/Basi_and_dingo.pdf 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 [http://www.gl-como.it/wp-content/uploads/2012/09/Linux_in_Bticino_LinuxDay2012.pdf 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 [http://processors.wiki.ti.com/index.php/DaVinci_GIT_Linux_Kernel#Overview] CodeSourcery's ''GNU Toolchain for ARM Processors'', version ''2009q1-203'', which can be downloaded as a [http://www.codesourcery.com/sgpp/lite/arm/portal/package4573/public/arm-none-linux-gnueabi/arm-2009q1-203-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2 tar archive] (or a [http://www.codesourcery.com/sgpp/lite/arm/portal/package4573/public/arm-none-linux-gnueabi/arm-2009q1-203-arm-none-linux-gnueabi.bin self-extracting archive], ''bigger not recommended'').

TI's [http://arago-project.org Arago Project] also refers to that specific tool chain version [http://arago-project.org/wiki/index.php/Getting_CodeSourcery_Toolchain] - 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 [http://www.myopen-legrandgroup.com/devices/gateways/m/f454_-_003598/45317.aspx 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 [http://www.ti.com/lit/pdf/sprufg5 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 [https://gitorious.org/ gitorious.org] in repository called [https://gitorious.org/medium_platform/bubl/source/90833fe26b0c5a833054e939909fc887c94561d9: medium_platform/bubl].

As of this writing, the latest commit has the hash [https://gitorious.org/medium_platform/bubl/commit/90833fe26b0c5a833054e939909fc887c94561d9 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 [https://gitorious.org/medium_platform/bubl/source/90833fe26b0c5a833054e939909fc887c94561d9:main.c#L109 steps]:

* setup PLL(s)
* setup timer(s)
* setup ADC
* setup DDR memory controller
* output (using UART0) various [https://gitorious.org/medium_platform/bubl/source/90833fe26b0c5a833054e939909fc887c94561d9:main.c#L44 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 [https://gitorious.org/medium_platform/bubl/source/90833fe26b0c5a833054e939909fc887c94561d9:main.c#L202 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 [https://gitorious.org/medium_platform/bubl/source/90833fe26b0c5a833054e939909fc887c94561d9:main.c#L270 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:

<source lang="bash">
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
</source>
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 [http://github.com/MyOpenCommunity MyOpenCommunity] site on [http://github.com 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: [http://github.com/MyOpenCommunity/u-boot-davinci-medium/commit/3ed2d264ae41bbc05f961a8aececdd636cdb1582 3ed2d264ae41bbc05f961a8aececdd636cdb1582].

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

* arago-project.org [http://arago-project.org/git/projects/?p=u-boot-davinci.git;a=summary U-Boot for DaVinci], tag [http://arago-project.org/git/projects/?p=u-boot-davinci.git;a=commit;h=6ebeaa9ef432217def1213e9cc611771d6412b1c DEV.DavinviBSP.03.01.01.38] (commit [http://arago-project.org/git/projects/?p=u-boot-davinci.git;a=commit;h=6ebeaa9ef432217def1213e9cc611771d6412b1c 6ebeaa9])
* denx.de [http://www.denx.de/wiki/U-Boot/WebHome U-Boot], some commits after tag [http://git.denx.de/?p=u-boot.git;a=commit;h=d0d2271f8c62e830ec65fb069b6d12dd708e3e2f v2010.12-rc2] (commit [http://git.denx.de/?p=u-boot.git;a=commit;h=f8689b f8689b])

Note that arago-project.org does also have a tag [http://arago-project.org/git/projects/?p=u-boot-davinci.git;a=commit;h=1af61f3b812b51f6f41ff37cd4a52ce6cfb21d7a 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 [http://github.com/MyOpenCommunity MyOpenCommunity] also has a repository called [http://github.com/MyOpenCommunity/u-boot-davinci-medium-v2 u-boot-davinci-medium-v2]. This is newer version, based on denx.de's U-Boot (commit [http://git.denx.de/?p=u-boot.git;a=commit;h=d41b3cc16fd97da23900f79e8fefdeedeebde8f6 d41b3cc]) - somewhere between versions [http://git.denx.de/?p=u-boot.git;a=commit;h=ebbf0d20aa85f623c49b7ed3349ebfea450c152d v2013.01-rc2] and [http://git.denx.de/?p=u-boot.git;a=commit;h=3ae7b240ad8c723d02aa79654220a07049b7ae4d 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:
<source lang="bash">
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
</source>

So, the used [http://kernel.org Linux] kernel is apparently based on [http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tag/?h=linux-2.6.32.y&id=v2.6.32.17 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:
<source lang="bash">
$ 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
</source>

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 [http://arago-project.org/ Arago project]: tag [http://arago-project.org/git/projects/?p=linux-davinci.git;a=commit;h=161e942bbb6e3603bccd1548865cfcce0910f1cc 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 [http://github.com GitHub]: http://github.com/MyOpenCommunity/linux-davinci-medium . It comprises the commit with the hash [http://github.com/MyOpenCommunity/linux-davinci-medium/commit/8ed3c294c0a661d818ffab0b94c381289740d429 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 [http://github.com/MyOpenCommunity/linux-davinci-medium repository]. Commits of firmware version 1.00.xx kernels are part of a branch called [https://github.com/MyOpenCommunity/linux-davinci-medium/tree/f454_1 f454_1]. Commits of firmware version 2.00.xx kernels can be found on the [https://github.com/MyOpenCommunity/linux-davinci-medium/tree/basi basi] branch.

{| class="wikitable"
! style="text-align:left;"| firmware version
! style="text-align:left;"| compile stamp
! style="text-align:left;"| kernel version
! style="text-align:left;"| commit hash
|-
|v1.00.34
|Thu Nov 8 17:02:20 CET 2012
|v2.6.32.17-davinci1
|[http://github.com/MyOpenCommunity/linux-davinci-medium/commit/8ed3c294c0a661d818ffab0b94c381289740d429 8ed3c294c0a661d818ffab0b94c381289740d429]
|-
|v1.00.37
|Thu Nov 8 17:02:20 CET 2012
|v2.6.32.17-davinci1
|[http://github.com/MyOpenCommunity/linux-davinci-medium/commit/8ed3c294c0a661d818ffab0b94c381289740d429 8ed3c294c0a661d818ffab0b94c381289740d429]
|-
|v1.00.45
|Fri Jan 17 17:16:09 CET 2014
|v2.6.32.17-davinci1
|[http://github.com/MyOpenCommunity/linux-davinci-medium/commit/59f7438a4e85d0a2b1b985a65500a9f05366f6ce 59f7438a4e85d0a2b1b985a65500a9f05366f6ce]
|-
|v1.00.51
|Thu Sep 4 18:03:59 CEST 2014
|v2.6.32.17-davinci1
|[http://github.com/MyOpenCommunity/linux-davinci-medium/commit/f56c4d42a889cb71bd92d101e9e2b0e847ca1603 f56c4d42a889cb71bd92d101e9e2b0e847ca1603]
|-
|v2.00.46
|Wed Oct 28 10:51:58 CET 2015
|v2.6.32.17-davinci1
|[http://github.com/MyOpenCommunity/linux-davinci-medium/commit/c44221b9cd7e82d5ec494320685310d138f4dd07 c44221b9cd7e82d5ec494320685310d138f4dd07]
|-
|v2.00.48
|Thu Jan 7 18:34:50 CET 2016
|v2.6.32.17-davinci1
|[http://github.com/MyOpenCommunity/linux-davinci-medium/commit/c44221b9cd7e82d5ec494320685310d138f4dd07 c44221b9cd7e82d5ec494320685310d138f4dd07]
|-
|v2.00.50
|Thu Feb 11 10:07:14 CET 2016
|v2.6.32.17-davinci1
|[http://github.com/MyOpenCommunity/linux-davinci-medium/commit/c44221b9cd7e82d5ec494320685310d138f4dd07 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:

<source lang="bash">
# 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
</source>

It turns out that all four different firmware v1.00.xx kernel versions known so far do have exactly the same configuration. The configuration of the firmware v2.00.xx kernel versions are different from the v1.00.xx ones. However within the v2.00.xx ones it is again the same configuration. The only differences within one family, say between v1.00.xx and v1.00.yy is the typical timestamp which is placed at the beginning of Linux kernel configuration files.

{| class="wikitable"
! style="text-align:left;"| firmware version
! style="text-align:left;"| time stamp
! style="text-align:left;"| 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
|-
|v2.00.46
|Wed Oct 28 10:49:54 2015
|20b4d997b4a307cb01d2a156f7551179
|-
|v2.00.48
|Thu Jan 7 18:33:28 2016
|eea14c82b90beb0bb3ba4ba2ccdb91d8
|-
|v2.00.50
|Thu Feb 11 10:05:41 2016
|0725aaa72d3d58dd0c89e4d4ee5a5458
|}

The following list shows some of the enabled features of both, v1.00.xx and v2.00.xx kernels '''''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)

The firmware v2.00.xx kernels do have additional features enabled. Again the list shows just the ones which might be surprising to see.

* network
** bridge (module)
*** stp (module)
*** netfilter, ebtables including DNAT, SNAT (modules)
** IPv4
*** netfilter, iptables including connection tracking, NAT, MASQ, STATE, ... (modules)
** IPv6
*** netfilter, iptables including connection tracking, STATE, ... (modules)
* filesystems
** devtmpfs

On an F454 running firmware version v1.00.37, the following modules are loaded:
<source lang="bash">
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
</source>

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

Bticino F454

2016-10-03T15:41:19Z

Joft: Add info about firmware v2.00.xx kernel configurations.

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 [http://www.ti.com/product/tms320dm365 DM365] SoC, from 2009. The Wikipedia page [http://en.wikipedia.org/wiki/Texas_Instruments_DaVinci Texas Instruments DaVinci] can be used as a first overview.

== CPU ==

The SoC does include, among many peripherals, an [http://en.wikipedia.org/wiki/List_of_ARM_microarchitectures ARM processor]:

* family: [http://en.wikipedia.org/wiki/ARM9E 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:
<source lang="bash">
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
</source>

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

<source lang="bash">
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
</source>

{| class="wikitable"
! style="text-align:left;"| input
! style="text-align:left;"| label
! style="text-align:left;"| typical value
! style="text-align:left;"| 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:
<source lang="bash">
root@basi:/sys/devices/virtual/gpio# cat /proc/meminfo | head -n 1
MemTotal: 103968 kB
</source>

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 [http://www.ti.com/lit/ug/sprufh2/sprufh2.pdf], 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 [http://www.ti.com/lit/ug/sprufi1c/sprufi1c.pdf Asynchronous External Memory Interface] of the DM365.

Within Linux they are represented by ''ttySx'' character device nodes:
<source lang="bash">
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
</source>
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:
{| class="wikitable"
! style="text-align:left;"| UART
! style="text-align:left;"| Linux device node
! style="text-align:left;"| usage
! style="text-align:left;"| 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:
<source lang="bash">
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
</source>

=== Accessibility ===

Bticino's F454 [http://www.homesystems-legrandgroup.com/technicalDocuments/type5/MQ00519-b-EN.pdf 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 [http://en.wikipedia.org/wiki/Master_boot_record MBR] style:

{| class="wikitable"
! style="text-align:left;"| partition
! style="text-align:left;"| start sector
! style="text-align:left;"| size in sectors / in KiB
! style="text-align:left;"| 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 [http://it.linkedin.com/pub/raffaele-recalcati/b/7b/3a9 Raffaele Recalcati] on [https://archive.fosdem.org/2011 FOSDEM 2011] provides some more details: [https://archive.fosdem.org/2011/schedule/event/davinci.html DaVinci dm365 for home automation] [http://free-electrons.com/pub/video/2011/fosdem/fosdem2011-recalcati-home-automation.webm Video] [http://elinux.org/images/1/1f/Basi_and_dingo.pdf 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 [http://www.gl-como.it/wp-content/uploads/2012/09/Linux_in_Bticino_LinuxDay2012.pdf 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 [http://processors.wiki.ti.com/index.php/DaVinci_GIT_Linux_Kernel#Overview] CodeSourcery's ''GNU Toolchain for ARM Processors'', version ''2009q1-203'', which can be downloaded as a [http://www.codesourcery.com/sgpp/lite/arm/portal/package4573/public/arm-none-linux-gnueabi/arm-2009q1-203-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2 tar archive] (or a [http://www.codesourcery.com/sgpp/lite/arm/portal/package4573/public/arm-none-linux-gnueabi/arm-2009q1-203-arm-none-linux-gnueabi.bin self-extracting archive], ''bigger not recommended'').

TI's [http://arago-project.org Arago Project] also refers to that specific tool chain version [http://arago-project.org/wiki/index.php/Getting_CodeSourcery_Toolchain] - 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 [http://www.myopen-legrandgroup.com/devices/gateways/m/f454_-_003598/45317.aspx 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 [http://www.ti.com/lit/pdf/sprufg5 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 [https://gitorious.org/ gitorious.org] in repository called [https://gitorious.org/medium_platform/bubl/source/90833fe26b0c5a833054e939909fc887c94561d9: medium_platform/bubl].

As of this writing, the latest commit has the hash [https://gitorious.org/medium_platform/bubl/commit/90833fe26b0c5a833054e939909fc887c94561d9 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 [https://gitorious.org/medium_platform/bubl/source/90833fe26b0c5a833054e939909fc887c94561d9:main.c#L109 steps]:

* setup PLL(s)
* setup timer(s)
* setup ADC
* setup DDR memory controller
* output (using UART0) various [https://gitorious.org/medium_platform/bubl/source/90833fe26b0c5a833054e939909fc887c94561d9:main.c#L44 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 [https://gitorious.org/medium_platform/bubl/source/90833fe26b0c5a833054e939909fc887c94561d9:main.c#L202 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 [https://gitorious.org/medium_platform/bubl/source/90833fe26b0c5a833054e939909fc887c94561d9:main.c#L270 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:

<source lang="bash">
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
</source>
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 [http://github.com/MyOpenCommunity MyOpenCommunity] site on [http://github.com 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: [http://github.com/MyOpenCommunity/u-boot-davinci-medium/commit/3ed2d264ae41bbc05f961a8aececdd636cdb1582 3ed2d264ae41bbc05f961a8aececdd636cdb1582].

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

* arago-project.org [http://arago-project.org/git/projects/?p=u-boot-davinci.git;a=summary U-Boot for DaVinci], tag [http://arago-project.org/git/projects/?p=u-boot-davinci.git;a=commit;h=6ebeaa9ef432217def1213e9cc611771d6412b1c DEV.DavinviBSP.03.01.01.38] (commit [http://arago-project.org/git/projects/?p=u-boot-davinci.git;a=commit;h=6ebeaa9ef432217def1213e9cc611771d6412b1c 6ebeaa9])
* denx.de [http://www.denx.de/wiki/U-Boot/WebHome U-Boot], some commits after tag [http://git.denx.de/?p=u-boot.git;a=commit;h=d0d2271f8c62e830ec65fb069b6d12dd708e3e2f v2010.12-rc2] (commit [http://git.denx.de/?p=u-boot.git;a=commit;h=f8689b f8689b])

Note that arago-project.org does also have a tag [http://arago-project.org/git/projects/?p=u-boot-davinci.git;a=commit;h=1af61f3b812b51f6f41ff37cd4a52ce6cfb21d7a 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 [http://github.com/MyOpenCommunity MyOpenCommunity] also has a repository called [http://github.com/MyOpenCommunity/u-boot-davinci-medium-v2 u-boot-davinci-medium-v2]. This is newer version, based on denx.de's U-Boot (commit [http://git.denx.de/?p=u-boot.git;a=commit;h=d41b3cc16fd97da23900f79e8fefdeedeebde8f6 d41b3cc]) - somewhere between versions [http://git.denx.de/?p=u-boot.git;a=commit;h=ebbf0d20aa85f623c49b7ed3349ebfea450c152d v2013.01-rc2] and [http://git.denx.de/?p=u-boot.git;a=commit;h=3ae7b240ad8c723d02aa79654220a07049b7ae4d 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:
<source lang="bash">
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
</source>

So, the used [http://kernel.org Linux] kernel is apparently based on [http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tag/?h=linux-2.6.32.y&id=v2.6.32.17 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:
<source lang="bash">
$ 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
</source>

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 [http://arago-project.org/ Arago project]: tag [http://arago-project.org/git/projects/?p=linux-davinci.git;a=commit;h=161e942bbb6e3603bccd1548865cfcce0910f1cc 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 [http://github.com GitHub]: http://github.com/MyOpenCommunity/linux-davinci-medium . It comprises the commit with the hash [http://github.com/MyOpenCommunity/linux-davinci-medium/commit/8ed3c294c0a661d818ffab0b94c381289740d429 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 [http://github.com/MyOpenCommunity/linux-davinci-medium repository]. Commits of firmware version 1.00.xx kernels are part of a branch called [https://github.com/MyOpenCommunity/linux-davinci-medium/tree/f454_1 f454_1]. Commits of firmware version 2.00.xx kernels can be found on the [https://github.com/MyOpenCommunity/linux-davinci-medium/tree/basi basi] branch.

{| class="wikitable"
! style="text-align:left;"| firmware version
! style="text-align:left;"| compile stamp
! style="text-align:left;"| kernel version
! style="text-align:left;"| commit hash
|-
|v1.00.34
|Thu Nov 8 17:02:20 CET 2012
|v2.6.32.17-davinci1
|[http://github.com/MyOpenCommunity/linux-davinci-medium/commit/8ed3c294c0a661d818ffab0b94c381289740d429 8ed3c294c0a661d818ffab0b94c381289740d429]
|-
|v1.00.37
|Thu Nov 8 17:02:20 CET 2012
|v2.6.32.17-davinci1
|[http://github.com/MyOpenCommunity/linux-davinci-medium/commit/8ed3c294c0a661d818ffab0b94c381289740d429 8ed3c294c0a661d818ffab0b94c381289740d429]
|-
|v1.00.45
|Fri Jan 17 17:16:09 CET 2014
|v2.6.32.17-davinci1
|[http://github.com/MyOpenCommunity/linux-davinci-medium/commit/59f7438a4e85d0a2b1b985a65500a9f05366f6ce 59f7438a4e85d0a2b1b985a65500a9f05366f6ce]
|-
|v1.00.51
|Thu Sep 4 18:03:59 CEST 2014
|v2.6.32.17-davinci1
|[http://github.com/MyOpenCommunity/linux-davinci-medium/commit/f56c4d42a889cb71bd92d101e9e2b0e847ca1603 f56c4d42a889cb71bd92d101e9e2b0e847ca1603]
|-
|v2.00.46
|Wed Oct 28 10:51:58 CET 2015
|v2.6.32.17-davinci1
|[http://github.com/MyOpenCommunity/linux-davinci-medium/commit/c44221b9cd7e82d5ec494320685310d138f4dd07 c44221b9cd7e82d5ec494320685310d138f4dd07]
|-
|v2.00.48
|Thu Jan 7 18:34:50 CET 2016
|v2.6.32.17-davinci1
|[http://github.com/MyOpenCommunity/linux-davinci-medium/commit/c44221b9cd7e82d5ec494320685310d138f4dd07 c44221b9cd7e82d5ec494320685310d138f4dd07]
|-
|v2.00.50
|Thu Feb 11 10:07:14 CET 2016
|v2.6.32.17-davinci1
|[http://github.com/MyOpenCommunity/linux-davinci-medium/commit/c44221b9cd7e82d5ec494320685310d138f4dd07 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:

<source lang="bash">
# 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
</source>

It turns out that all four different firmware v1.00.xx kernel versions known so far do have exactly the same configuration. The configuration of the firmware v2.00.xx kernel versions are different from the v1.00.xx ones. However within the v2.00.xx ones it is again the same configuration. The only differences within one family, say between v1.00.xx and v1.00.yy is the typical timestamp which is placed at the beginning of Linux kernel configuration files.

{| class="wikitable"
! style="text-align:left;"| firmware version
! style="text-align:left;"| time stamp
! style="text-align:left;"| 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
|-
|v2.00.46
|Wed Oct 28 10:49:54 2015
|20b4d997b4a307cb01d2a156f7551179
|-
|v2.00.48
|Thu Jan 7 18:33:28 2016
|eea14c82b90beb0bb3ba4ba2ccdb91d8
|-
|v2.00.50
|Thu Feb 11 10:05:41 2016
|0725aaa72d3d58dd0c89e4d4ee5a5458
|}

The following list shows some of the enabled features of both, v1.00.xx and v2.00.xx kernels '''''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)

The firmware v2.00.xx kernels do have additional features enabled. Again the list shows just the ones which might be surprising to see.

* network
** bridge (module)
*** stp (module)
*** netfilter, ebtables including DNAT, SNAT (modules)
** IPv4
*** netfilter, iptables including connection tracking, NAT, MASQ, STATE, ... (modules)
** IPv6
*** netfilter, iptables including connection tracking, STATE, ... (modules)
* filesystems
** devtmpfs

On an F454 running firmware version v1.00.37, the following modules are loaded:
<source lang="bash">
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
</source>

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

Bticino F454

2016-10-03T15:16:20Z

Joft: Add info about firmware version 2.00.xx kernels.

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 [http://www.ti.com/product/tms320dm365 DM365] SoC, from 2009. The Wikipedia page [http://en.wikipedia.org/wiki/Texas_Instruments_DaVinci Texas Instruments DaVinci] can be used as a first overview.

== CPU ==

The SoC does include, among many peripherals, an [http://en.wikipedia.org/wiki/List_of_ARM_microarchitectures ARM processor]:

* family: [http://en.wikipedia.org/wiki/ARM9E 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:
<source lang="bash">
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
</source>

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

<source lang="bash">
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
</source>

{| class="wikitable"
! style="text-align:left;"| input
! style="text-align:left;"| label
! style="text-align:left;"| typical value
! style="text-align:left;"| 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:
<source lang="bash">
root@basi:/sys/devices/virtual/gpio# cat /proc/meminfo | head -n 1
MemTotal: 103968 kB
</source>

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 [http://www.ti.com/lit/ug/sprufh2/sprufh2.pdf], 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 [http://www.ti.com/lit/ug/sprufi1c/sprufi1c.pdf Asynchronous External Memory Interface] of the DM365.

Within Linux they are represented by ''ttySx'' character device nodes:
<source lang="bash">
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
</source>
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:
{| class="wikitable"
! style="text-align:left;"| UART
! style="text-align:left;"| Linux device node
! style="text-align:left;"| usage
! style="text-align:left;"| 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:
<source lang="bash">
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
</source>

=== Accessibility ===

Bticino's F454 [http://www.homesystems-legrandgroup.com/technicalDocuments/type5/MQ00519-b-EN.pdf 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 [http://en.wikipedia.org/wiki/Master_boot_record MBR] style:

{| class="wikitable"
! style="text-align:left;"| partition
! style="text-align:left;"| start sector
! style="text-align:left;"| size in sectors / in KiB
! style="text-align:left;"| 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 [http://it.linkedin.com/pub/raffaele-recalcati/b/7b/3a9 Raffaele Recalcati] on [https://archive.fosdem.org/2011 FOSDEM 2011] provides some more details: [https://archive.fosdem.org/2011/schedule/event/davinci.html DaVinci dm365 for home automation] [http://free-electrons.com/pub/video/2011/fosdem/fosdem2011-recalcati-home-automation.webm Video] [http://elinux.org/images/1/1f/Basi_and_dingo.pdf 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 [http://www.gl-como.it/wp-content/uploads/2012/09/Linux_in_Bticino_LinuxDay2012.pdf 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 [http://processors.wiki.ti.com/index.php/DaVinci_GIT_Linux_Kernel#Overview] CodeSourcery's ''GNU Toolchain for ARM Processors'', version ''2009q1-203'', which can be downloaded as a [http://www.codesourcery.com/sgpp/lite/arm/portal/package4573/public/arm-none-linux-gnueabi/arm-2009q1-203-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2 tar archive] (or a [http://www.codesourcery.com/sgpp/lite/arm/portal/package4573/public/arm-none-linux-gnueabi/arm-2009q1-203-arm-none-linux-gnueabi.bin self-extracting archive], ''bigger not recommended'').

TI's [http://arago-project.org Arago Project] also refers to that specific tool chain version [http://arago-project.org/wiki/index.php/Getting_CodeSourcery_Toolchain] - 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 [http://www.myopen-legrandgroup.com/devices/gateways/m/f454_-_003598/45317.aspx 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 [http://www.ti.com/lit/pdf/sprufg5 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 [https://gitorious.org/ gitorious.org] in repository called [https://gitorious.org/medium_platform/bubl/source/90833fe26b0c5a833054e939909fc887c94561d9: medium_platform/bubl].

As of this writing, the latest commit has the hash [https://gitorious.org/medium_platform/bubl/commit/90833fe26b0c5a833054e939909fc887c94561d9 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 [https://gitorious.org/medium_platform/bubl/source/90833fe26b0c5a833054e939909fc887c94561d9:main.c#L109 steps]:

* setup PLL(s)
* setup timer(s)
* setup ADC
* setup DDR memory controller
* output (using UART0) various [https://gitorious.org/medium_platform/bubl/source/90833fe26b0c5a833054e939909fc887c94561d9:main.c#L44 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 [https://gitorious.org/medium_platform/bubl/source/90833fe26b0c5a833054e939909fc887c94561d9:main.c#L202 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 [https://gitorious.org/medium_platform/bubl/source/90833fe26b0c5a833054e939909fc887c94561d9:main.c#L270 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:

<source lang="bash">
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
</source>
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 [http://github.com/MyOpenCommunity MyOpenCommunity] site on [http://github.com 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: [http://github.com/MyOpenCommunity/u-boot-davinci-medium/commit/3ed2d264ae41bbc05f961a8aececdd636cdb1582 3ed2d264ae41bbc05f961a8aececdd636cdb1582].

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

* arago-project.org [http://arago-project.org/git/projects/?p=u-boot-davinci.git;a=summary U-Boot for DaVinci], tag [http://arago-project.org/git/projects/?p=u-boot-davinci.git;a=commit;h=6ebeaa9ef432217def1213e9cc611771d6412b1c DEV.DavinviBSP.03.01.01.38] (commit [http://arago-project.org/git/projects/?p=u-boot-davinci.git;a=commit;h=6ebeaa9ef432217def1213e9cc611771d6412b1c 6ebeaa9])
* denx.de [http://www.denx.de/wiki/U-Boot/WebHome U-Boot], some commits after tag [http://git.denx.de/?p=u-boot.git;a=commit;h=d0d2271f8c62e830ec65fb069b6d12dd708e3e2f v2010.12-rc2] (commit [http://git.denx.de/?p=u-boot.git;a=commit;h=f8689b f8689b])

Note that arago-project.org does also have a tag [http://arago-project.org/git/projects/?p=u-boot-davinci.git;a=commit;h=1af61f3b812b51f6f41ff37cd4a52ce6cfb21d7a 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 [http://github.com/MyOpenCommunity MyOpenCommunity] also has a repository called [http://github.com/MyOpenCommunity/u-boot-davinci-medium-v2 u-boot-davinci-medium-v2]. This is newer version, based on denx.de's U-Boot (commit [http://git.denx.de/?p=u-boot.git;a=commit;h=d41b3cc16fd97da23900f79e8fefdeedeebde8f6 d41b3cc]) - somewhere between versions [http://git.denx.de/?p=u-boot.git;a=commit;h=ebbf0d20aa85f623c49b7ed3349ebfea450c152d v2013.01-rc2] and [http://git.denx.de/?p=u-boot.git;a=commit;h=3ae7b240ad8c723d02aa79654220a07049b7ae4d 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:
<source lang="bash">
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
</source>

So, the used [http://kernel.org Linux] kernel is apparently based on [http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tag/?h=linux-2.6.32.y&id=v2.6.32.17 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:
<source lang="bash">
$ 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
</source>

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 [http://arago-project.org/ Arago project]: tag [http://arago-project.org/git/projects/?p=linux-davinci.git;a=commit;h=161e942bbb6e3603bccd1548865cfcce0910f1cc 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 [http://github.com GitHub]: http://github.com/MyOpenCommunity/linux-davinci-medium . It comprises the commit with the hash [http://github.com/MyOpenCommunity/linux-davinci-medium/commit/8ed3c294c0a661d818ffab0b94c381289740d429 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 [http://github.com/MyOpenCommunity/linux-davinci-medium repository]. Commits of firmware version 1.00.xx kernels are part of a branch called [https://github.com/MyOpenCommunity/linux-davinci-medium/tree/f454_1 f454_1]. Commits of firmware version 2.00.xx kernels can be found on the [https://github.com/MyOpenCommunity/linux-davinci-medium/tree/basi basi] branch.

{| class="wikitable"
! style="text-align:left;"| firmware version
! style="text-align:left;"| compile stamp
! style="text-align:left;"| kernel version
! style="text-align:left;"| commit hash
|-
|v1.00.34
|Thu Nov 8 17:02:20 CET 2012
|v2.6.32.17-davinci1
|[http://github.com/MyOpenCommunity/linux-davinci-medium/commit/8ed3c294c0a661d818ffab0b94c381289740d429 8ed3c294c0a661d818ffab0b94c381289740d429]
|-
|v1.00.37
|Thu Nov 8 17:02:20 CET 2012
|v2.6.32.17-davinci1
|[http://github.com/MyOpenCommunity/linux-davinci-medium/commit/8ed3c294c0a661d818ffab0b94c381289740d429 8ed3c294c0a661d818ffab0b94c381289740d429]
|-
|v1.00.45
|Fri Jan 17 17:16:09 CET 2014
|v2.6.32.17-davinci1
|[http://github.com/MyOpenCommunity/linux-davinci-medium/commit/59f7438a4e85d0a2b1b985a65500a9f05366f6ce 59f7438a4e85d0a2b1b985a65500a9f05366f6ce]
|-
|v1.00.51
|Thu Sep 4 18:03:59 CEST 2014
|v2.6.32.17-davinci1
|[http://github.com/MyOpenCommunity/linux-davinci-medium/commit/f56c4d42a889cb71bd92d101e9e2b0e847ca1603 f56c4d42a889cb71bd92d101e9e2b0e847ca1603]
|-
|v2.00.46
|Wed Oct 28 10:51:58 CET 2015
|v2.6.32.17-davinci1
|[http://github.com/MyOpenCommunity/linux-davinci-medium/commit/c44221b9cd7e82d5ec494320685310d138f4dd07 c44221b9cd7e82d5ec494320685310d138f4dd07]
|-
|v2.00.48
|Thu Jan 7 18:34:50 CET 2016
|v2.6.32.17-davinci1
|[http://github.com/MyOpenCommunity/linux-davinci-medium/commit/c44221b9cd7e82d5ec494320685310d138f4dd07 c44221b9cd7e82d5ec494320685310d138f4dd07]
|-
|v2.00.50
|Thu Feb 11 10:07:14 CET 2016
|v2.6.32.17-davinci1
|[http://github.com/MyOpenCommunity/linux-davinci-medium/commit/c44221b9cd7e82d5ec494320685310d138f4dd07 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:

<source lang="bash">
# 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
</source>

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.

{| class="wikitable"
! style="text-align:left;"| firmware version
! style="text-align:left;"| time stamp
! style="text-align:left;"| 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:
<source lang="bash">
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
</source>

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

Bticino F454

2015-03-12T08:32:12Z

Joft: /* Boot loader */ RBL, fix ambiguity in various statements.

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 [http://www.ti.com/product/tms320dm365 DM365] SoC, from 2009. The Wikipedia page [http://en.wikipedia.org/wiki/Texas_Instruments_DaVinci Texas Instruments DaVinci] can be used as a first overview.

== CPU ==

The SoC does include, among many peripherals, an [http://en.wikipedia.org/wiki/List_of_ARM_microarchitectures ARM processor]:

* family: [http://en.wikipedia.org/wiki/ARM9E 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:
<source lang="bash">
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
</source>

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

<source lang="bash">
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
</source>

{| class="wikitable"
! style="text-align:left;"| input
! style="text-align:left;"| label
! style="text-align:left;"| typical value
! style="text-align:left;"| 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:
<source lang="bash">
root@basi:/sys/devices/virtual/gpio# cat /proc/meminfo | head -n 1
MemTotal: 103968 kB
</source>

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 [http://www.ti.com/lit/ug/sprufh2/sprufh2.pdf], 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 [http://www.ti.com/lit/ug/sprufi1c/sprufi1c.pdf Asynchronous External Memory Interface] of the DM365.

Within Linux they are represented by ''ttySx'' character device nodes:
<source lang="bash">
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
</source>
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:
{| class="wikitable"
! style="text-align:left;"| UART
! style="text-align:left;"| Linux device node
! style="text-align:left;"| usage
! style="text-align:left;"| 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:
<source lang="bash">
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
</source>

=== Accessibility ===

Bticino's F454 [http://www.homesystems-legrandgroup.com/technicalDocuments/type5/MQ00519-b-EN.pdf 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 [http://en.wikipedia.org/wiki/Master_boot_record MBR] style:

{| class="wikitable"
! style="text-align:left;"| partition
! style="text-align:left;"| start sector
! style="text-align:left;"| size in sectors / in KiB
! style="text-align:left;"| 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 [http://it.linkedin.com/pub/raffaele-recalcati/b/7b/3a9 Raffaele Recalcati] on [https://archive.fosdem.org/2011 FOSDEM 2011] provides some more details: [https://archive.fosdem.org/2011/schedule/event/davinci.html DaVinci dm365 for home automation] [http://free-electrons.com/pub/video/2011/fosdem/fosdem2011-recalcati-home-automation.webm Video] [http://elinux.org/images/1/1f/Basi_and_dingo.pdf 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 [http://www.gl-como.it/wp-content/uploads/2012/09/Linux_in_Bticino_LinuxDay2012.pdf 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 [http://processors.wiki.ti.com/index.php/DaVinci_GIT_Linux_Kernel#Overview] CodeSourcery's ''GNU Toolchain for ARM Processors'', version ''2009q1-203'', which can be downloaded as a [http://www.codesourcery.com/sgpp/lite/arm/portal/package4573/public/arm-none-linux-gnueabi/arm-2009q1-203-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2 tar archive] (or a [http://www.codesourcery.com/sgpp/lite/arm/portal/package4573/public/arm-none-linux-gnueabi/arm-2009q1-203-arm-none-linux-gnueabi.bin self-extracting archive], ''bigger not recommended'').

TI's [http://arago-project.org Arago Project] also refers to that specific tool chain version [http://arago-project.org/wiki/index.php/Getting_CodeSourcery_Toolchain] - 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 [http://www.myopen-legrandgroup.com/devices/gateways/m/f454_-_003598/45317.aspx 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 [http://www.ti.com/lit/pdf/sprufg5 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 [https://gitorious.org/ gitorious.org] in repository called [https://gitorious.org/medium_platform/bubl/source/90833fe26b0c5a833054e939909fc887c94561d9: medium_platform/bubl].

As of this writing, the latest commit has the hash [https://gitorious.org/medium_platform/bubl/commit/90833fe26b0c5a833054e939909fc887c94561d9 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 [https://gitorious.org/medium_platform/bubl/source/90833fe26b0c5a833054e939909fc887c94561d9:main.c#L109 steps]:

* setup PLL(s)
* setup timer(s)
* setup ADC
* setup DDR memory controller
* output (using UART0) various [https://gitorious.org/medium_platform/bubl/source/90833fe26b0c5a833054e939909fc887c94561d9:main.c#L44 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 [https://gitorious.org/medium_platform/bubl/source/90833fe26b0c5a833054e939909fc887c94561d9:main.c#L202 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 [https://gitorious.org/medium_platform/bubl/source/90833fe26b0c5a833054e939909fc887c94561d9:main.c#L270 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:

<source lang="bash">
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
</source>
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 [http://github.com/MyOpenCommunity MyOpenCommunity] site on [http://github.com 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: [http://github.com/MyOpenCommunity/u-boot-davinci-medium/commit/3ed2d264ae41bbc05f961a8aececdd636cdb1582 3ed2d264ae41bbc05f961a8aececdd636cdb1582].

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

* arago-project.org [http://arago-project.org/git/projects/?p=u-boot-davinci.git;a=summary U-Boot for DaVinci], tag [http://arago-project.org/git/projects/?p=u-boot-davinci.git;a=commit;h=6ebeaa9ef432217def1213e9cc611771d6412b1c DEV.DavinviBSP.03.01.01.38] (commit [http://arago-project.org/git/projects/?p=u-boot-davinci.git;a=commit;h=6ebeaa9ef432217def1213e9cc611771d6412b1c 6ebeaa9])
* denx.de [http://www.denx.de/wiki/U-Boot/WebHome U-Boot], some commits after tag [http://git.denx.de/?p=u-boot.git;a=commit;h=d0d2271f8c62e830ec65fb069b6d12dd708e3e2f v2010.12-rc2] (commit [http://git.denx.de/?p=u-boot.git;a=commit;h=f8689b f8689b])

Note that arago-project.org does also have a tag [http://arago-project.org/git/projects/?p=u-boot-davinci.git;a=commit;h=1af61f3b812b51f6f41ff37cd4a52ce6cfb21d7a 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 [http://github.com/MyOpenCommunity MyOpenCommunity] also has a repository called [http://github.com/MyOpenCommunity/u-boot-davinci-medium-v2 u-boot-davinci-medium-v2]. This is newer version, based on denx.de's U-Boot (commit [http://git.denx.de/?p=u-boot.git;a=commit;h=d41b3cc16fd97da23900f79e8fefdeedeebde8f6 d41b3cc]) - somewhere between versions [http://git.denx.de/?p=u-boot.git;a=commit;h=ebbf0d20aa85f623c49b7ed3349ebfea450c152d v2013.01-rc2] and [http://git.denx.de/?p=u-boot.git;a=commit;h=3ae7b240ad8c723d02aa79654220a07049b7ae4d 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:
<source lang="bash">
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
</source>

So, the used [http://kernel.org Linux] kernel is apparently based on [http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tag/?h=linux-2.6.32.y&id=v2.6.32.17 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:
<source lang="bash">
$ 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
</source>

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 [http://arago-project.org/ Arago project]: tag [http://arago-project.org/git/projects/?p=linux-davinci.git;a=commit;h=161e942bbb6e3603bccd1548865cfcce0910f1cc 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 [http://github.com GitHub]: http://github.com/MyOpenCommunity/linux-davinci-medium . It comprises the commit with the hash [http://github.com/MyOpenCommunity/linux-davinci-medium/commit/8ed3c294c0a661d818ffab0b94c381289740d429 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 [http://github.com/MyOpenCommunity/linux-davinci-medium repository]. All these commits are part of a branch called [https://github.com/MyOpenCommunity/linux-davinci-medium/tree/f454_1 f454_1].

{| class="wikitable"
! style="text-align:left;"| firmware version
! style="text-align:left;"| compile stamp
! style="text-align:left;"| kernel version
! style="text-align:left;"| commit hash
|-
|v1.00.34
|Thu Nov 8 17:02:20 CET 2012
|v2.6.32.17-davinci1
|[http://github.com/MyOpenCommunity/linux-davinci-medium/commit/8ed3c294c0a661d818ffab0b94c381289740d429 8ed3c294c0a661d818ffab0b94c381289740d429]
|-
|v1.00.37
|Thu Nov 8 17:02:20 CET 2012
|v2.6.32.17-davinci1
|[http://github.com/MyOpenCommunity/linux-davinci-medium/commit/8ed3c294c0a661d818ffab0b94c381289740d429 8ed3c294c0a661d818ffab0b94c381289740d429]
|-
|v1.00.45
|Fri Jan 17 17:16:09 CET 2014
|v2.6.32.17-davinci1
|[http://github.com/MyOpenCommunity/linux-davinci-medium/commit/59f7438a4e85d0a2b1b985a65500a9f05366f6ce 59f7438a4e85d0a2b1b985a65500a9f05366f6ce]
|-
|v1.00.51
|Thu Sep 4 18:03:59 CEST 2014
|v2.6.32.17-davinci1
|[http://github.com/MyOpenCommunity/linux-davinci-medium/commit/f56c4d42a889cb71bd92d101e9e2b0e847ca1603 f56c4d42a889cb71bd92d101e9e2b0e847ca1603]
|}

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

<source lang="bash">
# 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
</source>

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.

{| class="wikitable"
! style="text-align:left;"| firmware version
! style="text-align:left;"| time stamp
! style="text-align:left;"| 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:
<source lang="bash">
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
</source>

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

Bticino F454

2015-02-28T12:18:25Z

Joft: /* Hardware */ Add info about serial interfaces.

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 [http://www.ti.com/product/tms320dm365 DM365] SoC, from 2009. The Wikipedia page [http://en.wikipedia.org/wiki/Texas_Instruments_DaVinci Texas Instruments DaVinci] can be used as a first overview.

== CPU ==

The SoC does include, among many peripherals, an [http://en.wikipedia.org/wiki/List_of_ARM_microarchitectures ARM processor]:

* family: [http://en.wikipedia.org/wiki/ARM9E 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:
<source lang="bash">
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
</source>

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

<source lang="bash">
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
</source>

{| class="wikitable"
! style="text-align:left;"| input
! style="text-align:left;"| label
! style="text-align:left;"| typical value
! style="text-align:left;"| 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:
<source lang="bash">
root@basi:/sys/devices/virtual/gpio# cat /proc/meminfo | head -n 1
MemTotal: 103968 kB
</source>

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 [http://www.ti.com/lit/ug/sprufh2/sprufh2.pdf], 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 [http://www.ti.com/lit/ug/sprufi1c/sprufi1c.pdf Asynchronous External Memory Interface] of the DM365.

Within Linux they are represented by ''ttySx'' character device nodes:
<source lang="bash">
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
</source>
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:
{| class="wikitable"
! style="text-align:left;"| UART
! style="text-align:left;"| Linux device node
! style="text-align:left;"| usage
! style="text-align:left;"| 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:
<source lang="bash">
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
</source>

=== Accessibility ===

Bticino's F454 [http://www.homesystems-legrandgroup.com/technicalDocuments/type5/MQ00519-b-EN.pdf 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 [http://en.wikipedia.org/wiki/Master_boot_record MBR] style:

{| class="wikitable"
! style="text-align:left;"| partition
! style="text-align:left;"| start sector
! style="text-align:left;"| size in sectors / in KiB
! style="text-align:left;"| 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 [http://it.linkedin.com/pub/raffaele-recalcati/b/7b/3a9 Raffaele Recalcati] on [https://archive.fosdem.org/2011 FOSDEM 2011] provides some more details: [https://archive.fosdem.org/2011/schedule/event/davinci.html DaVinci dm365 for home automation] [http://free-electrons.com/pub/video/2011/fosdem/fosdem2011-recalcati-home-automation.webm Video] [http://elinux.org/images/1/1f/Basi_and_dingo.pdf 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 [http://www.gl-como.it/wp-content/uploads/2012/09/Linux_in_Bticino_LinuxDay2012.pdf 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 [http://processors.wiki.ti.com/index.php/DaVinci_GIT_Linux_Kernel#Overview] CodeSourcery's ''GNU Toolchain for ARM Processors'', version ''2009q1-203'', which can be downloaded as a [http://www.codesourcery.com/sgpp/lite/arm/portal/package4573/public/arm-none-linux-gnueabi/arm-2009q1-203-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2 tar archive] (or a [http://www.codesourcery.com/sgpp/lite/arm/portal/package4573/public/arm-none-linux-gnueabi/arm-2009q1-203-arm-none-linux-gnueabi.bin self-extracting archive], ''bigger not recommended'').

TI's [http://arago-project.org Arago Project] also refers to that specific tool chain version [http://arago-project.org/wiki/index.php/Getting_CodeSourcery_Toolchain] - 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 [http://www.myopen-legrandgroup.com/devices/gateways/m/f454_-_003598/45317.aspx 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 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 [http://www.ti.com/lit/pdf/sprufg5 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 [https://gitorious.org/ gitorious.org] in repository called [https://gitorious.org/medium_platform/bubl/source/90833fe26b0c5a833054e939909fc887c94561d9: medium_platform/bubl].

As of this writing, the latest commit has the hash [https://gitorious.org/medium_platform/bubl/commit/90833fe26b0c5a833054e939909fc887c94561d9 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 [https://gitorious.org/medium_platform/bubl/source/90833fe26b0c5a833054e939909fc887c94561d9:main.c#L109 steps]:

* setup PLL(s)
* setup timer(s)
* setup ADC
* setup DDR memory controller
* output (using UART0) various [https://gitorious.org/medium_platform/bubl/source/90833fe26b0c5a833054e939909fc887c94561d9:main.c#L44 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 [https://gitorious.org/medium_platform/bubl/source/90833fe26b0c5a833054e939909fc887c94561d9:main.c#L202 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 [https://gitorious.org/medium_platform/bubl/source/90833fe26b0c5a833054e939909fc887c94561d9:main.c#L270 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:

<source lang="bash">
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
</source>
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 [http://github.com/MyOpenCommunity MyOpenCommunity] site on [http://github.com 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: [http://github.com/MyOpenCommunity/u-boot-davinci-medium/commit/3ed2d264ae41bbc05f961a8aececdd636cdb1582 3ed2d264ae41bbc05f961a8aececdd636cdb1582].

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

* arago-project.org [http://arago-project.org/git/projects/?p=u-boot-davinci.git;a=summary U-Boot for DaVinci], tag [http://arago-project.org/git/projects/?p=u-boot-davinci.git;a=commit;h=6ebeaa9ef432217def1213e9cc611771d6412b1c DEV.DavinviBSP.03.01.01.38] (commit [http://arago-project.org/git/projects/?p=u-boot-davinci.git;a=commit;h=6ebeaa9ef432217def1213e9cc611771d6412b1c 6ebeaa9])
* denx.de [http://www.denx.de/wiki/U-Boot/WebHome U-Boot], some commits after tag [http://git.denx.de/?p=u-boot.git;a=commit;h=d0d2271f8c62e830ec65fb069b6d12dd708e3e2f v2010.12-rc2] (commit [http://git.denx.de/?p=u-boot.git;a=commit;h=f8689b f8689b])

Note that arago-project.org does also have a tag [http://arago-project.org/git/projects/?p=u-boot-davinci.git;a=commit;h=1af61f3b812b51f6f41ff37cd4a52ce6cfb21d7a 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 [http://github.com/MyOpenCommunity MyOpenCommunity] also has a repository called [http://github.com/MyOpenCommunity/u-boot-davinci-medium-v2 u-boot-davinci-medium-v2]. This is newer version, based on denx.de's U-Boot (commit [http://git.denx.de/?p=u-boot.git;a=commit;h=d41b3cc16fd97da23900f79e8fefdeedeebde8f6 d41b3cc]) - somewhere between versions [http://git.denx.de/?p=u-boot.git;a=commit;h=ebbf0d20aa85f623c49b7ed3349ebfea450c152d v2013.01-rc2] and [http://git.denx.de/?p=u-boot.git;a=commit;h=3ae7b240ad8c723d02aa79654220a07049b7ae4d 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:
<source lang="bash">
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
</source>

So, the used [http://kernel.org Linux] kernel is apparently based on [http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tag/?h=linux-2.6.32.y&id=v2.6.32.17 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:
<source lang="bash">
$ 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
</source>

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 [http://arago-project.org/ Arago project]: tag [http://arago-project.org/git/projects/?p=linux-davinci.git;a=commit;h=161e942bbb6e3603bccd1548865cfcce0910f1cc 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 [http://github.com GitHub]: http://github.com/MyOpenCommunity/linux-davinci-medium . It comprises the commit with the hash [http://github.com/MyOpenCommunity/linux-davinci-medium/commit/8ed3c294c0a661d818ffab0b94c381289740d429 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 [http://github.com/MyOpenCommunity/linux-davinci-medium repository]. All these commits are part of a branch called [https://github.com/MyOpenCommunity/linux-davinci-medium/tree/f454_1 f454_1].

{| class="wikitable"
! style="text-align:left;"| firmware version
! style="text-align:left;"| compile stamp
! style="text-align:left;"| kernel version
! style="text-align:left;"| commit hash
|-
|v1.00.34
|Thu Nov 8 17:02:20 CET 2012
|v2.6.32.17-davinci1
|[http://github.com/MyOpenCommunity/linux-davinci-medium/commit/8ed3c294c0a661d818ffab0b94c381289740d429 8ed3c294c0a661d818ffab0b94c381289740d429]
|-
|v1.00.37
|Thu Nov 8 17:02:20 CET 2012
|v2.6.32.17-davinci1
|[http://github.com/MyOpenCommunity/linux-davinci-medium/commit/8ed3c294c0a661d818ffab0b94c381289740d429 8ed3c294c0a661d818ffab0b94c381289740d429]
|-
|v1.00.45
|Fri Jan 17 17:16:09 CET 2014
|v2.6.32.17-davinci1
|[http://github.com/MyOpenCommunity/linux-davinci-medium/commit/59f7438a4e85d0a2b1b985a65500a9f05366f6ce 59f7438a4e85d0a2b1b985a65500a9f05366f6ce]
|-
|v1.00.51
|Thu Sep 4 18:03:59 CEST 2014
|v2.6.32.17-davinci1
|[http://github.com/MyOpenCommunity/linux-davinci-medium/commit/f56c4d42a889cb71bd92d101e9e2b0e847ca1603 f56c4d42a889cb71bd92d101e9e2b0e847ca1603]
|}

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

<source lang="bash">
# 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
</source>

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.

{| class="wikitable"
! style="text-align:left;"| firmware version
! style="text-align:left;"| time stamp
! style="text-align:left;"| 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:
<source lang="bash">
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
</source>

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

Bticino F454

2015-02-28T10:28:10Z

Joft: /* Tool Chain */ Start to fill in this section.

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 [http://www.ti.com/product/tms320dm365 DM365] SoC, from 2009. The Wikipedia page [http://en.wikipedia.org/wiki/Texas_Instruments_DaVinci Texas Instruments DaVinci] can be used as a first overview.

== CPU ==

The SoC does include, among many peripherals, an [http://en.wikipedia.org/wiki/List_of_ARM_microarchitectures ARM processor]:

* family: [http://en.wikipedia.org/wiki/ARM9E 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:
<source lang="bash">
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
</source>

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

<source lang="bash">
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
</source>

{| class="wikitable"
! style="text-align:left;"| input
! style="text-align:left;"| label
! style="text-align:left;"| typical value
! style="text-align:left;"| 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:
<source lang="bash">
root@basi:/sys/devices/virtual/gpio# cat /proc/meminfo | head -n 1
MemTotal: 103968 kB
</source>

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 [http://en.wikipedia.org/wiki/Master_boot_record MBR] style:

{| class="wikitable"
! style="text-align:left;"| partition
! style="text-align:left;"| start sector
! style="text-align:left;"| size in sectors / in KiB
! style="text-align:left;"| 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 [http://it.linkedin.com/pub/raffaele-recalcati/b/7b/3a9 Raffaele Recalcati] on [https://archive.fosdem.org/2011 FOSDEM 2011] provides some more details: [https://archive.fosdem.org/2011/schedule/event/davinci.html DaVinci dm365 for home automation] [http://free-electrons.com/pub/video/2011/fosdem/fosdem2011-recalcati-home-automation.webm Video] [http://elinux.org/images/1/1f/Basi_and_dingo.pdf 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 [http://www.gl-como.it/wp-content/uploads/2012/09/Linux_in_Bticino_LinuxDay2012.pdf 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 [http://processors.wiki.ti.com/index.php/DaVinci_GIT_Linux_Kernel#Overview] CodeSourcery's ''GNU Toolchain for ARM Processors'', version ''2009q1-203'', which can be downloaded as a [http://www.codesourcery.com/sgpp/lite/arm/portal/package4573/public/arm-none-linux-gnueabi/arm-2009q1-203-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2 tar archive] (or a [http://www.codesourcery.com/sgpp/lite/arm/portal/package4573/public/arm-none-linux-gnueabi/arm-2009q1-203-arm-none-linux-gnueabi.bin self-extracting archive], ''bigger not recommended'').

TI's [http://arago-project.org Arago Project] also refers to that specific tool chain version [http://arago-project.org/wiki/index.php/Getting_CodeSourcery_Toolchain] - 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 [http://www.myopen-legrandgroup.com/devices/gateways/m/f454_-_003598/45317.aspx 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 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 [http://www.ti.com/lit/pdf/sprufg5 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 [https://gitorious.org/ gitorious.org] in repository called [https://gitorious.org/medium_platform/bubl/source/90833fe26b0c5a833054e939909fc887c94561d9: medium_platform/bubl].

As of this writing, the latest commit has the hash [https://gitorious.org/medium_platform/bubl/commit/90833fe26b0c5a833054e939909fc887c94561d9 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 [https://gitorious.org/medium_platform/bubl/source/90833fe26b0c5a833054e939909fc887c94561d9:main.c#L109 steps]:

* setup PLL(s)
* setup timer(s)
* setup ADC
* setup DDR memory controller
* output (using UART0) various [https://gitorious.org/medium_platform/bubl/source/90833fe26b0c5a833054e939909fc887c94561d9:main.c#L44 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 [https://gitorious.org/medium_platform/bubl/source/90833fe26b0c5a833054e939909fc887c94561d9:main.c#L202 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 [https://gitorious.org/medium_platform/bubl/source/90833fe26b0c5a833054e939909fc887c94561d9:main.c#L270 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:

<source lang="bash">
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
</source>
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 [http://github.com/MyOpenCommunity MyOpenCommunity] site on [http://github.com 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: [http://github.com/MyOpenCommunity/u-boot-davinci-medium/commit/3ed2d264ae41bbc05f961a8aececdd636cdb1582 3ed2d264ae41bbc05f961a8aececdd636cdb1582].

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

* arago-project.org [http://arago-project.org/git/projects/?p=u-boot-davinci.git;a=summary U-Boot for DaVinci], tag [http://arago-project.org/git/projects/?p=u-boot-davinci.git;a=commit;h=6ebeaa9ef432217def1213e9cc611771d6412b1c DEV.DavinviBSP.03.01.01.38] (commit [http://arago-project.org/git/projects/?p=u-boot-davinci.git;a=commit;h=6ebeaa9ef432217def1213e9cc611771d6412b1c 6ebeaa9])
* denx.de [http://www.denx.de/wiki/U-Boot/WebHome U-Boot], some commits after tag [http://git.denx.de/?p=u-boot.git;a=commit;h=d0d2271f8c62e830ec65fb069b6d12dd708e3e2f v2010.12-rc2] (commit [http://git.denx.de/?p=u-boot.git;a=commit;h=f8689b f8689b])

Note that arago-project.org does also have a tag [http://arago-project.org/git/projects/?p=u-boot-davinci.git;a=commit;h=1af61f3b812b51f6f41ff37cd4a52ce6cfb21d7a 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 [http://github.com/MyOpenCommunity MyOpenCommunity] also has a repository called [http://github.com/MyOpenCommunity/u-boot-davinci-medium-v2 u-boot-davinci-medium-v2]. This is newer version, based on denx.de's U-Boot (commit [http://git.denx.de/?p=u-boot.git;a=commit;h=d41b3cc16fd97da23900f79e8fefdeedeebde8f6 d41b3cc]) - somewhere between versions [http://git.denx.de/?p=u-boot.git;a=commit;h=ebbf0d20aa85f623c49b7ed3349ebfea450c152d v2013.01-rc2] and [http://git.denx.de/?p=u-boot.git;a=commit;h=3ae7b240ad8c723d02aa79654220a07049b7ae4d 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:
<source lang="bash">
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
</source>

So, the used [http://kernel.org Linux] kernel is apparently based on [http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tag/?h=linux-2.6.32.y&id=v2.6.32.17 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:
<source lang="bash">
$ 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
</source>

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 [http://arago-project.org/ Arago project]: tag [http://arago-project.org/git/projects/?p=linux-davinci.git;a=commit;h=161e942bbb6e3603bccd1548865cfcce0910f1cc 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 [http://github.com GitHub]: http://github.com/MyOpenCommunity/linux-davinci-medium . It comprises the commit with the hash [http://github.com/MyOpenCommunity/linux-davinci-medium/commit/8ed3c294c0a661d818ffab0b94c381289740d429 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 [http://github.com/MyOpenCommunity/linux-davinci-medium repository]. All these commits are part of a branch called [https://github.com/MyOpenCommunity/linux-davinci-medium/tree/f454_1 f454_1].

{| class="wikitable"
! style="text-align:left;"| firmware version
! style="text-align:left;"| compile stamp
! style="text-align:left;"| kernel version
! style="text-align:left;"| commit hash
|-
|v1.00.34
|Thu Nov 8 17:02:20 CET 2012
|v2.6.32.17-davinci1
|[http://github.com/MyOpenCommunity/linux-davinci-medium/commit/8ed3c294c0a661d818ffab0b94c381289740d429 8ed3c294c0a661d818ffab0b94c381289740d429]
|-
|v1.00.37
|Thu Nov 8 17:02:20 CET 2012
|v2.6.32.17-davinci1
|[http://github.com/MyOpenCommunity/linux-davinci-medium/commit/8ed3c294c0a661d818ffab0b94c381289740d429 8ed3c294c0a661d818ffab0b94c381289740d429]
|-
|v1.00.45
|Fri Jan 17 17:16:09 CET 2014
|v2.6.32.17-davinci1
|[http://github.com/MyOpenCommunity/linux-davinci-medium/commit/59f7438a4e85d0a2b1b985a65500a9f05366f6ce 59f7438a4e85d0a2b1b985a65500a9f05366f6ce]
|-
|v1.00.51
|Thu Sep 4 18:03:59 CEST 2014
|v2.6.32.17-davinci1
|[http://github.com/MyOpenCommunity/linux-davinci-medium/commit/f56c4d42a889cb71bd92d101e9e2b0e847ca1603 f56c4d42a889cb71bd92d101e9e2b0e847ca1603]
|}

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

<source lang="bash">
# 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
</source>

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.

{| class="wikitable"
! style="text-align:left;"| firmware version
! style="text-align:left;"| time stamp
! style="text-align:left;"| 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:
<source lang="bash">
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
</source>

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

Bticino F454

2015-02-27T20:02:36Z

Joft: /* Origin */ Point to n recently published U-Boot source code, show grep version from binary.

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 [http://www.ti.com/product/tms320dm365 DM365] SoC, from 2009. The Wikipedia page [http://en.wikipedia.org/wiki/Texas_Instruments_DaVinci Texas Instruments DaVinci] can be used as a first overview.

== CPU ==

The SoC does include, among many peripherals, an [http://en.wikipedia.org/wiki/List_of_ARM_microarchitectures ARM processor]:

* family: [http://en.wikipedia.org/wiki/ARM9E 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:
<source lang="bash">
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
</source>

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

<source lang="bash">
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
</source>

{| class="wikitable"
! style="text-align:left;"| input
! style="text-align:left;"| label
! style="text-align:left;"| typical value
! style="text-align:left;"| 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:
<source lang="bash">
root@basi:/sys/devices/virtual/gpio# cat /proc/meminfo | head -n 1
MemTotal: 103968 kB
</source>

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 [http://en.wikipedia.org/wiki/Master_boot_record MBR] style:

{| class="wikitable"
! style="text-align:left;"| partition
! style="text-align:left;"| start sector
! style="text-align:left;"| size in sectors / in KiB
! style="text-align:left;"| 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 [http://it.linkedin.com/pub/raffaele-recalcati/b/7b/3a9 Raffaele Recalcati] on [https://archive.fosdem.org/2011 FOSDEM 2011] provides some more details: [https://archive.fosdem.org/2011/schedule/event/davinci.html DaVinci dm365 for home automation] [http://free-electrons.com/pub/video/2011/fosdem/fosdem2011-recalcati-home-automation.webm Video] [http://elinux.org/images/1/1f/Basi_and_dingo.pdf 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 [http://www.gl-como.it/wp-content/uploads/2012/09/Linux_in_Bticino_LinuxDay2012.pdf 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 [http://www.ti.com/lit/pdf/sprufg5 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 [https://gitorious.org/ gitorious.org] in repository called [https://gitorious.org/medium_platform/bubl/source/90833fe26b0c5a833054e939909fc887c94561d9: medium_platform/bubl].

As of this writing, the latest commit has the hash [https://gitorious.org/medium_platform/bubl/commit/90833fe26b0c5a833054e939909fc887c94561d9 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 [https://gitorious.org/medium_platform/bubl/source/90833fe26b0c5a833054e939909fc887c94561d9:main.c#L109 steps]:

* setup PLL(s)
* setup timer(s)
* setup ADC
* setup DDR memory controller
* output (using UART0) various [https://gitorious.org/medium_platform/bubl/source/90833fe26b0c5a833054e939909fc887c94561d9:main.c#L44 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 [https://gitorious.org/medium_platform/bubl/source/90833fe26b0c5a833054e939909fc887c94561d9:main.c#L202 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 [https://gitorious.org/medium_platform/bubl/source/90833fe26b0c5a833054e939909fc887c94561d9:main.c#L270 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:

<source lang="bash">
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
</source>
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 [http://github.com/MyOpenCommunity MyOpenCommunity] site on [http://github.com 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: [http://github.com/MyOpenCommunity/u-boot-davinci-medium/commit/3ed2d264ae41bbc05f961a8aececdd636cdb1582 3ed2d264ae41bbc05f961a8aececdd636cdb1582].

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

* arago-project.org [http://arago-project.org/git/projects/?p=u-boot-davinci.git;a=summary U-Boot for DaVinci], tag [http://arago-project.org/git/projects/?p=u-boot-davinci.git;a=commit;h=6ebeaa9ef432217def1213e9cc611771d6412b1c DEV.DavinviBSP.03.01.01.38] (commit [http://arago-project.org/git/projects/?p=u-boot-davinci.git;a=commit;h=6ebeaa9ef432217def1213e9cc611771d6412b1c 6ebeaa9])
* denx.de [http://www.denx.de/wiki/U-Boot/WebHome U-Boot], some commits after tag [http://git.denx.de/?p=u-boot.git;a=commit;h=d0d2271f8c62e830ec65fb069b6d12dd708e3e2f v2010.12-rc2] (commit [http://git.denx.de/?p=u-boot.git;a=commit;h=f8689b f8689b])

Note that arago-project.org does also have a tag [http://arago-project.org/git/projects/?p=u-boot-davinci.git;a=commit;h=1af61f3b812b51f6f41ff37cd4a52ce6cfb21d7a 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 [http://github.com/MyOpenCommunity MyOpenCommunity] also has a repository called [http://github.com/MyOpenCommunity/u-boot-davinci-medium-v2 u-boot-davinci-medium-v2]. This is newer version, based on denx.de's U-Boot (commit [http://git.denx.de/?p=u-boot.git;a=commit;h=d41b3cc16fd97da23900f79e8fefdeedeebde8f6 d41b3cc]) - somewhere between versions [http://git.denx.de/?p=u-boot.git;a=commit;h=ebbf0d20aa85f623c49b7ed3349ebfea450c152d v2013.01-rc2] and [http://git.denx.de/?p=u-boot.git;a=commit;h=3ae7b240ad8c723d02aa79654220a07049b7ae4d 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:
<source lang="bash">
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
</source>

So, the used [http://kernel.org Linux] kernel is apparently based on [http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tag/?h=linux-2.6.32.y&id=v2.6.32.17 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:
<source lang="bash">
$ 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
</source>

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 [http://arago-project.org/ Arago project]: tag [http://arago-project.org/git/projects/?p=linux-davinci.git;a=commit;h=161e942bbb6e3603bccd1548865cfcce0910f1cc 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 [http://github.com GitHub]: http://github.com/MyOpenCommunity/linux-davinci-medium . It comprises the commit with the hash [http://github.com/MyOpenCommunity/linux-davinci-medium/commit/8ed3c294c0a661d818ffab0b94c381289740d429 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 [http://github.com/MyOpenCommunity/linux-davinci-medium repository]. All these commits are part of a branch called [https://github.com/MyOpenCommunity/linux-davinci-medium/tree/f454_1 f454_1].

{| class="wikitable"
! style="text-align:left;"| firmware version
! style="text-align:left;"| compile stamp
! style="text-align:left;"| kernel version
! style="text-align:left;"| commit hash
|-
|v1.00.34
|Thu Nov 8 17:02:20 CET 2012
|v2.6.32.17-davinci1
|[http://github.com/MyOpenCommunity/linux-davinci-medium/commit/8ed3c294c0a661d818ffab0b94c381289740d429 8ed3c294c0a661d818ffab0b94c381289740d429]
|-
|v1.00.37
|Thu Nov 8 17:02:20 CET 2012
|v2.6.32.17-davinci1
|[http://github.com/MyOpenCommunity/linux-davinci-medium/commit/8ed3c294c0a661d818ffab0b94c381289740d429 8ed3c294c0a661d818ffab0b94c381289740d429]
|-
|v1.00.45
|Fri Jan 17 17:16:09 CET 2014
|v2.6.32.17-davinci1
|[http://github.com/MyOpenCommunity/linux-davinci-medium/commit/59f7438a4e85d0a2b1b985a65500a9f05366f6ce 59f7438a4e85d0a2b1b985a65500a9f05366f6ce]
|-
|v1.00.51
|Thu Sep 4 18:03:59 CEST 2014
|v2.6.32.17-davinci1
|[http://github.com/MyOpenCommunity/linux-davinci-medium/commit/f56c4d42a889cb71bd92d101e9e2b0e847ca1603 f56c4d42a889cb71bd92d101e9e2b0e847ca1603]
|}

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

<source lang="bash">
# 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
</source>

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.

{| class="wikitable"
! style="text-align:left;"| firmware version
! style="text-align:left;"| time stamp
! style="text-align:left;"| 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:
<source lang="bash">
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
</source>

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

Bticino F454

2015-02-25T21:26:41Z

Joft: /* U-Boot */ Note on new bticino github repo, minor other changes ...

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 [http://www.ti.com/product/tms320dm365 DM365] SoC, from 2009. The Wikipedia page [http://en.wikipedia.org/wiki/Texas_Instruments_DaVinci Texas Instruments DaVinci] can be used as a first overview.

== CPU ==

The SoC does include, among many peripherals, an [http://en.wikipedia.org/wiki/List_of_ARM_microarchitectures ARM processor]:

* family: [http://en.wikipedia.org/wiki/ARM9E 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:
<source lang="bash">
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
</source>

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

<source lang="bash">
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
</source>

{| class="wikitable"
! style="text-align:left;"| input
! style="text-align:left;"| label
! style="text-align:left;"| typical value
! style="text-align:left;"| 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:
<source lang="bash">
root@basi:/sys/devices/virtual/gpio# cat /proc/meminfo | head -n 1
MemTotal: 103968 kB
</source>

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 [http://en.wikipedia.org/wiki/Master_boot_record MBR] style:

{| class="wikitable"
! style="text-align:left;"| partition
! style="text-align:left;"| start sector
! style="text-align:left;"| size in sectors / in KiB
! style="text-align:left;"| 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 [http://it.linkedin.com/pub/raffaele-recalcati/b/7b/3a9 Raffaele Recalcati] on [https://archive.fosdem.org/2011 FOSDEM 2011] provides some more details: [https://archive.fosdem.org/2011/schedule/event/davinci.html DaVinci dm365 for home automation] [http://free-electrons.com/pub/video/2011/fosdem/fosdem2011-recalcati-home-automation.webm Video] [http://elinux.org/images/1/1f/Basi_and_dingo.pdf 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 [http://www.gl-como.it/wp-content/uploads/2012/09/Linux_in_Bticino_LinuxDay2012.pdf 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 [http://www.ti.com/lit/pdf/sprufg5 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 [https://gitorious.org/ gitorious.org] in repository called [https://gitorious.org/medium_platform/bubl/source/90833fe26b0c5a833054e939909fc887c94561d9: medium_platform/bubl].

As of this writing, the latest commit has the hash [https://gitorious.org/medium_platform/bubl/commit/90833fe26b0c5a833054e939909fc887c94561d9 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 [https://gitorious.org/medium_platform/bubl/source/90833fe26b0c5a833054e939909fc887c94561d9:main.c#L109 steps]:

* setup PLL(s)
* setup timer(s)
* setup ADC
* setup DDR memory controller
* output (using UART0) various [https://gitorious.org/medium_platform/bubl/source/90833fe26b0c5a833054e939909fc887c94561d9:main.c#L44 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 [https://gitorious.org/medium_platform/bubl/source/90833fe26b0c5a833054e939909fc887c94561d9:main.c#L202 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 [https://gitorious.org/medium_platform/bubl/source/90833fe26b0c5a833054e939909fc887c94561d9:main.c#L270 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:

<source lang="bash">
root@basi:~# fw_printenv | grep ^ver= | sed 's#^ver=##'
U-Boot 2010.12-rc2-3ed2d264ae41bbc05f961a8aececdd636cdb1582 (Jul 23 2012 - 11:40:09)
</source>
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 [https://gitorious.org/ gitorious.org] repository: [https://gitorious.org/medium_platform/u-boot/source/f319d40632e77470d06d9d758633d106079eccf9: medium_platform/u-boot] .

It turns out that this repository's ''master'' branch (commit [https://gitorious.org/medium_platform/u-boot/commits/f319d40632e77470d06d9d758633d106079eccf9 f319d40]) has been derived from:

* arago-project.org [http://arago-project.org/git/projects/?p=u-boot-davinci.git;a=summary U-Boot for DaVinci], tag [http://arago-project.org/git/projects/?p=u-boot-davinci.git;a=commit;h=6ebeaa9ef432217def1213e9cc611771d6412b1c DEV.DavinviBSP.03.01.01.38] (commit [http://arago-project.org/git/projects/?p=u-boot-davinci.git;a=commit;h=6ebeaa9ef432217def1213e9cc611771d6412b1c 6ebeaa9])
* denx.de [http://www.denx.de/wiki/U-Boot/WebHome U-Boot], some commits after tag [http://git.denx.de/?p=u-boot.git;a=commit;h=d0d2271f8c62e830ec65fb069b6d12dd708e3e2f v2010.12-rc2] (commit [http://git.denx.de/?p=u-boot.git;a=commit;h=f8689b f8689b])

Note that arago-project.org does also have a tag [http://arago-project.org/git/projects/?p=u-boot-davinci.git;a=commit;h=1af61f3b812b51f6f41ff37cd4a52ce6cfb21d7a 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: bticino's more recent online presence regarding Git repositories on [http://github.com GitHub], named [http://github.com/MyOpenCommunity MyOpenCommunity], has a repository called [http://github.com/MyOpenCommunity/u-boot-davinci-medium-v2 u-boot-davinci-medium-v2]. However this is newer version, based on denx.de's U-Boot (commit [http://git.denx.de/?p=u-boot.git;a=commit;h=d41b3cc16fd97da23900f79e8fefdeedeebde8f6 d41b3cc]), which is somewhere between versions [http://git.denx.de/?p=u-boot.git;a=commit;h=ebbf0d20aa85f623c49b7ed3349ebfea450c152d v2013.01-rc2] and [http://git.denx.de/?p=u-boot.git;a=commit;h=3ae7b240ad8c723d02aa79654220a07049b7ae4d v2013.01-rc1] - and thus does '''not''' represent what is running on at least the F454 under investigation.

==== Operation ====

''TODO''

== Operating System ==

=== Kernel ===

==== Origin ====

A look at Linux' /proc/version and /boot, while running F454 firmware version 1.00.37, suggest:
<source lang="bash">
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
</source>

So, the used [http://kernel.org Linux] kernel is apparently based on [http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tag/?h=linux-2.6.32.y&id=v2.6.32.17 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:
<source lang="bash">
$ 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
</source>

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 [http://arago-project.org/ Arago project]: tag [http://arago-project.org/git/projects/?p=linux-davinci.git;a=commit;h=161e942bbb6e3603bccd1548865cfcce0910f1cc 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 [http://github.com GitHub]: http://github.com/MyOpenCommunity/linux-davinci-medium . It comprises the commit with the hash [http://github.com/MyOpenCommunity/linux-davinci-medium/commit/8ed3c294c0a661d818ffab0b94c381289740d429 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 [http://github.com/MyOpenCommunity/linux-davinci-medium repository]. All these commits are part of a branch called [https://github.com/MyOpenCommunity/linux-davinci-medium/tree/f454_1 f454_1].

{| class="wikitable"
! style="text-align:left;"| firmware version
! style="text-align:left;"| compile stamp
! style="text-align:left;"| kernel version
! style="text-align:left;"| commit hash
|-
|v1.00.34
|Thu Nov 8 17:02:20 CET 2012
|v2.6.32.17-davinci1
|[http://github.com/MyOpenCommunity/linux-davinci-medium/commit/8ed3c294c0a661d818ffab0b94c381289740d429 8ed3c294c0a661d818ffab0b94c381289740d429]
|-
|v1.00.37
|Thu Nov 8 17:02:20 CET 2012
|v2.6.32.17-davinci1
|[http://github.com/MyOpenCommunity/linux-davinci-medium/commit/8ed3c294c0a661d818ffab0b94c381289740d429 8ed3c294c0a661d818ffab0b94c381289740d429]
|-
|v1.00.45
|Fri Jan 17 17:16:09 CET 2014
|v2.6.32.17-davinci1
|[http://github.com/MyOpenCommunity/linux-davinci-medium/commit/59f7438a4e85d0a2b1b985a65500a9f05366f6ce 59f7438a4e85d0a2b1b985a65500a9f05366f6ce]
|-
|v1.00.51
|Thu Sep 4 18:03:59 CEST 2014
|v2.6.32.17-davinci1
|[http://github.com/MyOpenCommunity/linux-davinci-medium/commit/f56c4d42a889cb71bd92d101e9e2b0e847ca1603 f56c4d42a889cb71bd92d101e9e2b0e847ca1603]
|}

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

<source lang="bash">
# 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
</source>

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.

{| class="wikitable"
! style="text-align:left;"| firmware version
! style="text-align:left;"| time stamp
! style="text-align:left;"| 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:
<source lang="bash">
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
</source>

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

Bticino F454

2015-02-25T20:45:45Z

Joft: /* Origin */ Update and add further links to kernel source tree on github.

Bticino F454

2015-02-18T22:21:28Z

Joft: /* Configuration */

Bticino F454

2015-02-18T22:14:35Z

Joft: /* Configuration */

Bticino F454

2015-02-18T22:13:47Z

Joft: /* Kernel */ Add info about configuration of kernels.

Bticino F454

2015-02-18T09:10:03Z

Joft: /* Kernel */ Add compile time stamp; table of kernels

Bticino F454

2015-02-17T22:14:42Z

Joft: /* Kernel */ Add table of kernel version seen in different firmware versions.

Bticino F454

2015-02-17T09:09:09Z

Joft: /* Operating System */ Document origins of used Linux kernel

Bticino F454

2014-12-11T09:52:58Z

Joft: Start section about U-Boot, where it comes from.

Bticino F454

2014-12-09T09:58:50Z

Joft: Add info about the used UBL.

Bticino F454

2014-12-08T09:55:51Z

Joft: Add boot loader section, add info about th RBL.

Bticino F454

2014-12-07T20:35:52Z

Joft: Note U-Boot binary size.

Bticino F454

2014-12-07T20:31:17Z

Joft: Add info about suspected SPI EEPROM ...

Bticino F454

2014-11-27T22:09:07Z

Joft: Update memory info, 128MIB total.

Bticino F454

2014-11-27T22:03:38Z

Joft: Add info about storage.

Bticino F454

2014-11-27T09:44:37Z

Joft: Add info about RAM and mention HDVICP1.

Bticino F454

2014-11-27T09:39:37Z

Joft: Add links to publications about F454 hardware.

Bticino F454

2014-11-26T22:25:16Z

Joft: More hardware info - just found answer to speed question in my notes ...

Bticino F454

2014-11-26T10:50:52Z

Joft: Start page about F454.

WHO=13 - Device Communication

2014-11-23T13:10:48Z

Joft: Add DIMENSION codes found by experiment, missing from current official documentation.

WHO 13 let's you communicate with your gateway or scenario manager.

== We start with an Example ==
To find out what type of gateway and/or scenario manager you have, just send the message '''<tt>*#13**15##</tt>''' to your device, for example:
<source lang="bash">echo "*#13**15##" | netcat 192.168.60.201 20000</source>
This gives you a similar answer like this:
<pre style="background-color:#000000;color:#EEEEEE;">*#*1##*#13**15*12##*#*1##</pre>
My device is shown as '''12''', looking up in the Device Table below, the device must be a F453AV

== ATTRIBUTE Table ==
{| class="wikitable"
! style="text-align:left;"| ATTRIBUTE
! style="text-align:left;"| Description
! style="text-align:left;"| R/W
! style="text-align:left;"| Syntax
|- style="vertical-align:top;"
|0
|Time
|R/W
|Get Time: *#13**0## Set Time: *#13**#0*H*m*S*T##
|- style="vertical-align:top;"
|1
|Date
|R/W
|Get Date: *#13**1## Set Date: *#13**#1*W*D*M*Y##
|-
|10
|IP address
|R
|Get IP address: *#13**10##
|-
|11
|Net mask
|R
|Get Net mask: *#13**11##
|-
|12
|MAC address
|R
|Get MAC address: *#13**12##
|-
|15
|Device Type
|R
|Get Device Type: *#13**15##
|-
|16
|Firmware version
|R
|Get Firmware version: *#13**16##
|-
|19
|Uptime
|R
|Get Uptime: *#13**19##
|- style="vertical-align:top;"
|22
|Date and Time
|R/W
|Get DateTime: *#13**22## Set DateTime: *#13**#1*H*m*S*T*W*D*M*Y#
|-
|23
|Kernel Version
|R
|Get Kernel Version: *#13**23##
|-
|24
|Distribution Version
|R
|Get Distribution Version: *#13**24##
|}

The following attributes (DIMENSION codes) are '''not''' mentioned in the official documentation. However when looking at the results of requests using these codes their meaning seems obvious.
{| class="wikitable"
! style="text-align:left;"| ATTRIBUTE
! style="text-align:left;"| Description
! style="text-align:left;"| R/W
! style="text-align:left;"| Syntax
! style="text-align:left;"| Comment
|- style="vertical-align:top;"
|17
|Hardware Version
|R
|Get Hardware Version: *#13**17##
|
|-
|20
|Micro Version
|R
|Get Micro Version: *#13**20##
|most likely: version of SCS bus micro controller firmware
|-
|50
|Gateway IP address
|R
|Get Gateway IP address: *#13**50##
|
|-
|51
|DNS IP address 1
|R
|Get DNS IP address 1: *#13**51##
|
|-
|52
|DNS IP address 2
|R
|Get DNS IP address 2: *#13**52##
|
|}

{| class="wikitable"
! style="text-align:left;"| VALUE
! style="text-align:left;"| Description
! style="text-align:left;"| Info
|-
|H
|Hour
|2-digit value
|-
|m
|Minute
|2-digit value
|-
|S
|Second
|2-digit value
|-
|T
|Timezone
|
|-
|W
|Weekday
|
|-
|D
|Day
|2-digit value
|-
|M
|Month
|2-digit value
|-
|Y
|Year
|4-digit value
|}

== Device Table==
{| class="wikitable"
! style="text-align:left;"| OWN-ID
! style="text-align:left;"| Device
|-
|2
|MHServer
|-
|4
|MH200
|-
|6
|F452
|-
|7
|F452V
|-
|11
|MHServer2
|-
|12
|F453AV
|-
|13
|H4684
|-
|15
|F427 (Gateway Open-KNX)
|-
|16
|F453
|-
|23
|H4684
|-
|27
|L4686SDK
|-
|44
|MH200N
|-
|51
|F454
|}

Hacks and Tweaks

2014-11-23T11:41:15Z

Joft: Add note, FTP is stopped automatically.

== F454 ==

The following sections just list various bits and pieces of information - without any specific order - regarding the bticino [http://www.homesystems-legrandgroup.com/BtHomeSystems/productDetail.action?productId=006 F454]. Of course there is always the possibility that the given information also applies to other bticino components.

=== Known flaws ===

==== root w/o password ====
At least in firmware versions v1.00.34, v1.00.37 and v1.00.45 the user ''root'' of the Linux system running on a F454 does not have a password set - by default. To be precises: It is the ''blank'' password.

This issue has been reported to bticino via it's community forum [http://www.myopen-legrandgroup.com/ MY HOME] on 2013/12/17 23:23 (see [http://www.myopen-legrandgroup.com/community/international_my_open/international_65560/f/134/t/8589.aspx forum post]). However, there hasn't been any reaction from any bticino/legrand representative yet.

----

=== FTP ===

All bticino gateway devices, not only the F454, use FTP for configuration up- and download. However the FTP server daemon is not running by default. It is ''started'' by configuration software, like TiF454, when doing a configuration up- or download - via a OWN WHO=13 command (DIMENSION WRITING, DIMENSION 31, VAL1 0):

<code>*#13**#31*0##</code>

Note that DIMENSION 34 also seems to have something to do with ''starting'' the FTP server daemon. However it remains unclear what and why.

It can also be ''stopped'' again (DIMENSION WRITING, DIMENSION 33, VAL1 0):

<code>*#13**#33*0##</code>

Note that it seems to be ''stopped'' automatically after about 10 minutes - after having opened and closed a FTP connection.

----

=== SSH ===

startssh is a "custom app" for the bticino F454. Its purpose is to start the SSH daemon "dropbear" at startup to allow SSH logins. dropbear is actually already part of the F454 firmware (known: v1.00.34, v1.00.37), but not started automatically for unknown reasons.

The source code can be downloaded here:

https://github.com/joft/f454utils

To get started please have a look at the [https://github.com/joft/f454utils/blob/master/apps/startssh/README README] file.

''TODO for joft: Basically include README text here - or at least essential parts.''

Hacks and Tweaks

2014-11-23T11:36:13Z

Joft: Add how to start FTP on F454.

== F454 ==

The following sections just list various bits and pieces of information - without any specific order - regarding the bticino [http://www.homesystems-legrandgroup.com/BtHomeSystems/productDetail.action?productId=006 F454]. Of course there is always the possibility that the given information also applies to other bticino components.

=== Known flaws ===

==== root w/o password ====
At least in firmware versions v1.00.34, v1.00.37 and v1.00.45 the user ''root'' of the Linux system running on a F454 does not have a password set - by default. To be precises: It is the ''blank'' password.

This issue has been reported to bticino via it's community forum [http://www.myopen-legrandgroup.com/ MY HOME] on 2013/12/17 23:23 (see [http://www.myopen-legrandgroup.com/community/international_my_open/international_65560/f/134/t/8589.aspx forum post]). However, there hasn't been any reaction from any bticino/legrand representative yet.

----

=== FTP ===

All bticino gateway devices, not only the F454, use FTP for configuration up- and download. However the FTP server daemon is not running by default. It is ''started'' by configuration software, like TiF454, when doing a configuration up- or download - via a OWN WHO=13 command (DIMENSION WRITING, DIMENSION 31, VAL1 0):

<code>*#13**#31*0##</code>

Note that DIMENSION 34 also seems to have something to do with ''starting'' the FTP server daemon. However it remains unclear what and why.

It can also be ''stopped'' again (DIMENSION WRITING, DIMENSION 33, VAL1 0):

<code>*#13**#33*0##</code>

----

=== SSH ===

startssh is a "custom app" for the bticino F454. Its purpose is to start the SSH daemon "dropbear" at startup to allow SSH logins. dropbear is actually already part of the F454 firmware (known: v1.00.34, v1.00.37), but not started automatically for unknown reasons.

The source code can be downloaded here:

https://github.com/joft/f454utils

To get started please have a look at the [https://github.com/joft/f454utils/blob/master/apps/startssh/README README] file.

''TODO for joft: Basically include README text here - or at least essential parts.''

Hacks and Tweaks

2014-11-23T11:08:40Z

Joft: Start known flaws section - root w/o password issue.

== F454 ==

=== Known flaws ===

==== root w/o password ====
At least in firmware versions v1.00.34, v1.00.37 and v1.00.45 the user ''root'' of the Linux system running on a F454 does not have a password set - by default. To be precises: It is the ''blank'' password.

This issue has been reported to bticino via it's community forum [http://www.myopen-legrandgroup.com/ MY HOME] on 2013/12/17 23:23 (see [http://www.myopen-legrandgroup.com/community/international_my_open/international_65560/f/134/t/8589.aspx forum post]). However, there hasn't been any reaction from any bticino/legrand representative yet.

----

=== SSH ===

startssh is a "custom app" for the bticino F454. Its purpose is to start the SSH daemon "dropbear" at startup to allow SSH logins. dropbear is actually already part of the F454 firmware (known: v1.00.34, v1.00.37), but not started automatically for unknown reasons.

The source code can be downloaded here:

https://github.com/joft/f454utils

To get started please have a look at the [https://github.com/joft/f454utils/blob/master/apps/startssh/README README] file.

''TODO for joft: Basically include README text here - or at least essential parts.''

Hacks and Tweaks

2014-11-20T22:11:29Z

Joft: Start Hacks&Tweaks page: minimal first text about F454 startssh app.

== F454 ==

=== SSH ===

startssh is a "custom app" for the bticino F454. Its purpose is to start the SSH daemon "dropbear" at startup to allow SSH logins. dropbear is actually already part of the F454 firmware (known: v1.00.34, v1.00.37), but not started automatically for unknown reasons.

The source code can be downloaded here:

https://github.com/joft/f454utils

To get started please have a look at the [https://github.com/joft/f454utils/blob/master/apps/startssh/README README] file.

''TODO for joft: Basically include README text here - or at least essential parts.''