Difference between revisions of "Bticino F454"

From piMyHome Project
Jump to navigation Jump to search
(Add info about storage.)
(Add info about toolchains used for firmware v2.00.xx .)
 
(21 intermediate revisions by the same user not shown)
Line 81: Line 81:
 
</source>
 
</source>
  
−
Obviously there is no such thing as a 103968 kB RAM chip. So whatever size the RAM actually is - the assumption is that the rest of the RAM is associated with the DM365's HDVICP1 co-processor?
+
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).
 
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?''
 
''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 ==
 
== 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:
 
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:
Line 100: Line 182:
 
|1
 
|1
 
|4159 / 2079.5 KiB
 
|4159 / 2079.5 KiB
−
|U-Boot binary at ???; U-Boot environment at offset 0x5ee00, size 0x1000
+
|U-Boot binary at 0x00e00, size 0x028270<br>U-Boot environment at offset 0x5ee00, size 0x01000
 
|-
 
|-
 
|2
 
|2
Line 128: Line 210:
 
|}
 
|}
  
 +
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 ==
 
== Further information ==
Line 137: Line 228:
  
 
''TODO: more''
 
''TODO: more''
−
 
  
 
= Software =
 
= Software =
Line 143: Line 233:
 
== Tool Chain ==
 
== 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 ==
 
== Operating System ==
  
−
''TODO''
+
=== 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 ==
 
== Applications ==
  
 
''TODO''
 
''TODO''

Latest revision as of 18:42, 4 October 2016

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

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

Hardware

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

CPU

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

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

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

A look at Linux' /proc/cpuinfo confirms: 

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

Hardware	: BTicino BASI board
Revision	: 0000
Serial		: 0000000000000000

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

root@basi:~# cd /sys/devices/platform/bt_nexmed_hwmon.0
root@basi:/sys/devices/platform/bt_nexmed_hwmon.0# ls in* temp*
in1_input    in1_label    in2_input    in2_label    in4_input
in4_label    in5_input    in5_label    temp1_input  temp1_label
input label typical value comment
in1 Hw version 0
in2 board identification BASI BOARD
in4 cpu speed 270MHz
in5 board configuration 4 unknown - what does it mean?
temp1 Temperature 38 most likely in celcius?

Memory

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

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

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

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

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

Serial interfaces

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

Within Linux they are represented by ttySx character device nodes: 

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

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

The following table shows how these UARTs are used:

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

The settings can be verified by, for example: 

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

Accessibility

Bticino's F454 Technial Sheet documents there is a Serial connector RS232 behind the hatch of the F454's case, left of the 3 LEDs. It is 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 RS-232 interface. It turns out that it is a 3.3V tolerant 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.

pin 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 MBR style:

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

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

EEPROM

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

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

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

Further information

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


TODO: more

Software

Tool Chain

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

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

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: 

gcc version 4.3.3 (Sourcery G++ Lite 2009q1-203)

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

Firmware v2.00.xxx

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

gcc version 4.8.2 (GCC)

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

Poky (Yocto Project Reference Distro) 1.6.2

This suggests that the root filesystem is build using the Yocto Project build system and is derived from its reference distribution 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: 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 DM36x User's Guide ARM Subsystem has all the details, chapter 11.2.5, page 188.

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

User boot loader - UBL

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

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

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

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

BUBL completes the following steps:

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

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

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

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

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

The last step is to either jump

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

U-Boot

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

Origin

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

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

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

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

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

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

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

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

Operation

TODO

Operating System

Kernel

Origin

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

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

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

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

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

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

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

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

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

Configuration

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

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

It turns out that all 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.

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

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

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

TODO: more

Applications

TODO

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