Dune HD STB - BASIC DEVELOPMENT INFORMATION



Platforms

Sigma Designs 8642 platform:
   STB models:    Base 3.0, Prime 3.0, Smart D1/H1/B1, Max, Duo
   CPU:           MIPS 74Kf 667 MHz (little endian)
   Linux kernel:  2.6.22.19

Sigma Designs 8652 platform:
   STB models:    Lite 53D
   CPU:           MIPS 24Kf 500 MHz (little endian)
   Linux kernel:  2.6.22.19

Sigma Designs 8670 platform:
   STB models:    TV-101, TV-102p, TV-201*, TV-301.
   CPU:           MIPS 24Kf 700 MHz (little endian)
   Linux kernel:  2.6.29

Sigma Designs 8674 platform:
   STB models:    TV-102, TV-202*, Connect
   CPU:           MIPS 24Kf 700 MHz (little endian)
   Linux kernel:  2.6.32

Sigma Designs 8672 platform:
   STB models:    TV-303D, Base 3D, Connect 3D*
   CPU:           MIPS 74Kf 800 MHz (little endian)
   Linux kernel:  2.6.32

SIgma Designs 8756 platform:
   STB models:    TV-204
   CPU:           ARMv7 Cortex A9 1000 MHz (little endian)
   Linux kernel:  3.4.39.13

SIgma Designs 8758 platform:
   STB models:    TV-205, TV-206, Solo4K
   CPU:           ARMv7 Cortex A9 1200 MHz, dual core (little endian)
   Linux kernel:  3.4.39.13

Android platforms:
   STB models:    All new STB models 

NOTE: the models marked with "*" are not officially launched.

Toolchain


Toolchain for SMP86xx MIPS platforms

Toolchain version: gcc 4.3.3 (CodeSourcery mips-4.3-154)
Libc version: GNU libc 2.8 (Sourcery G++ Lite 4.3-154)

Download:
   http://www.codesourcery.com/sgpp/lite/mips/portal/package4432/public/mips-linux-gnu/mips-4.3-154-mips-linux-gnu-i686-pc-linux-gnu.tar.bz2

Usage instructions:

   Use "-EL" compile flag.
   E.g.:
        /path/to/mips-4.3/bin/mips-linux-gnu-gcc -EL -o a a.c

Toolchain for SMP87xx ARM platforms

Toolchain version: gcc 4.8.1 (Mentor arm-2013.11-33)
Libc version: GNU libc 2.18 (Sourcery G++ Lite 2013.11-33)

Download:
   http://sourcery.mentor.com/public/gnu_toolchain/arm-none-linux-gnueabi/arm-2013.11-33-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2

Toolchain for Android platforms

Android NDK version: r14b
Android NDK API level: 19

Download:
   https://dl.google.com/android/repository/android-ndk-r14b-linux-x86_64.zip

Usage instructions:
   $NDK/build/tools/make_standalone_toolchain.py --arch arm --api 19 --install-dir $TOOLCHAIN
   $TOOLCHAIN/bin/arm-linux-androideabi-gcc -mcpu=cortex-a7 -mfloat-abi=softfp -mfpu=neon -pie -o a a.c

Telnet access to STB

Sigma Designs platforms:
   http://files.dune-hd.com/sdk/misc/dune_service_telnetd.dsf

Android platforms:
   http://files.dune-hd.com/sdk/misc/dune_service_android_telnetd.dsf

Put this file onto a USB flash drive and "launch" it on the STB (go to
"Sources" menu, navigate into the USB flash drive, choose the file, and
press "ENTER" RC button). This will enable Telnet service on the STB (kept
till reboot).

login: root
password: <empty>

IP-address of the STB: see Setup / Information.

To automatically enable Telnet service on each STB boot:
   touch /config/telnetd
   sync

To remove automatic enabling of Telnet service:
   rm -f /config/telnetd
   sync

NOTE: When an STB is used to provide access to an operator's service, and
the operator does not want end users to be able to enable telnet access to
the STB (e.g. to ensure the requirements of content owners or DRM vendors,
or to protect from STB software/firmware modification by end users), the
operator's firmware version is typically configured to limit or completely
disable the described above possibility to enable telnet access to the STB
and the telnet service on the STB.

NOTE: The use of telnet access to STB is not intended to be and should not
be used by regular end users for the regular use an STB, it is intended to
be used only by specially qualified persons who perform software
development related works or, in some cases, technical support related
works, in contact with and under guidance of engineers of STB vendor or an
operator, based on official recommendations and instructions by the STB
vendor, thus ensuring that all implementation details of the STB hardware
and firmware (in particular, including all the STB security mechanisms) are
fully and properly taken into account. The use of telnet access to an STB
may potentially lead (immediately or later) to unexpected work of the STB
or even impossibility to use the STB at all, and is performed at the risk
of the person who does it. The use of telnet access to an STB means that
the person who does it understands all of the above and accepts this risk.
If any problem occurs as a direct or indirect consequence of the use of
telnet access to the STB or any commands performed in the telnet session or
any software installed or modified with the help of such commands, the
standard way to recover the STB firmware or STB settings may or may not
work, and a request to the technical support to restore the STB operation
may or may not help, and the STB warranty may be void. The use of any other
way (if available for a particular STB model and a particular firmware
version) to execute any Linux commands in the Linux OS running on the STB
(e.g. via DSF files, via PHP plugins, etc) or access any other
debug/development interfaces of the STB (if available for a particular STB
model and a firmware version), or exploit any bugs in the hardware or the
software (if such a possibility is identified) lead to the same risk.

SSH access to STB

All SDK firmware versions (Sigma Designs platforms) include also a built-in
SSH server, which is active by default, and support key-based
authentication.

For more information, please see here:
http://files.dune-hd.com/sdk/doc/html/sdk.html
=> "JS STB SDK" section
=> Download any js_stb_sdk-*.zip package
=> See js_stb_sdk-*/doc/README.txt
=> "SSH access to device" section

Custom firmware builds can include built-in SSH server too. Standard public
(retail) firmware versions do not include built-in SSH server.

ADB access to STB

On Android platforms, you can enable ADB in the following ways:

1) Standard way (as on any Android device): in Setup / System menu, enable
Developer settings, then enable USB debugging in Developer settings. After
that, you can use ADB to connect to the STB via network.

2) Use the following DSF file:
   http://files.dune-hd.com/sdk/misc/dune_service_adb_enable.dsf

Using standard ADB push/pull commands, you can easily copy files between the PC
and the memory of the STB.

Some examples of ADB usage:
   adb connect dune-IP-address
   # Here, you may need to confirm ADB access on TV screen of the STB
   adb push file /tmp/file
   adb pull /tmp/file file
   adb shell

NOTE: When an STB is used to provide access to an operator's service, and
the operator does not want end users to be able to enable ADB access to
the STB (e.g. to ensure the requirements of content owners or DRM vendors, or
to protect from STB software/firmware modification by end users), the
operator's firmware version is typically configured to limit or completely
disable ADB access to the STB.

Filesystem and partitions overview

Sigma Designs platforms:

   /
   /bin/
   /cdrom/
   /dev/
   /drivers/
   /etc/
   /fconfig/
   /home/
   /init*
   /lib/
   /linuxrc -> bin/busybox*
   /opt/
   /proc/
   /root/
   /sbin/
   /sys/
   /tmp/
   /usr/
   /var/
         RAM disk. Initialized on Linux kernel boot (the initial image of
         the RAM disk is a part of the Linux kernel). Changes are lost on
         STB reboot.

   /tango -> /tango3/
   /tango3/
   /firmware -> /tango3/firmware/
   /firmware_ext -> /tango3/firmware_ext/
         Main read-only partition (CRAMFS file system) storing the main
         parts of the firmware.

   /app
         (Only for models based on SMP8674 and SMP8672.) Special
         "container" flash memory partition which stores "tango.cramfs"
         file containing the CRAMFS image of the "tango" filesystem. This
         CRAMFS image is loop-mounted to /tango. The /app partition is by
         default mounted as read-only.
         87xx platforms: SQUASHFS filesystem and "tango.squashfs" file are
         used.

   /mnt/
   /config -> /mnt/config/
         Small read-write flash memory partition. Is used mostly to keep
         STB settings. Is always available.

   /flashdata/
         "Flash Memory Storage" mount point, automatically mounted by Dune.
         A bigger flash memory read-write partition. May not be available
         depending on the STB model and STB settings/state. More info:
            http://dune-hd.com/firmware/usb_flash_drive/
         87xx platforms: /mnt, /config and /flashdata reside in the same
         big flash memory partitions (/flashdata -> /mnt/flashdata).

   /persistfs/
         "System Storage" mount point, automatically mounted by Dune. May
         be absent. More info:
            http://dune-hd.com/firmware/usb_flash_drive/

   /tmp/mnt/storage/*
         Local storages (USB flash drives etc), automatically mounted by
         Dune. When a new local storage is connected to Dune, it is
         automatically mounted by Dune (note, it may be required to
         navigate in the GUI into "Sources" menu in order to force Dune to
         detect and automatically mount the storage).

   /D/
         "Main Storage" mount point, automatically created by Dune. May be
         absent. Just an alias to one of mount points in /tmp/mnt/storage.

   /tmp/mnt/network/*, /tmp/mnt/smb/*
         Network shares (NFS and SMB), automatically mounted by Dune. Dune
         mounts network shares when the user navigates into the share.

Android platforms:

   The following directories are used the same way as on Sigma Design platforms:
      /firmware            # resides in /system
      /firmware_ext        # resides in /system
      /config              # resides in /data
      /flashdata           # resides in /data
      /tmp/mnt/*

   The following directories are used the same way as in any Android device:
      /system              # read-only partition, is rewritten on firmware updates
      /data                # read-write parition, is kept on firmware updates

Storing your files on STB

If you need to keep your own files in the flash memory of Dune, put them
into /mnt (/config) partition. This partition typically has about 2MB of
available space.

If more space is needed, consider using /flashdata (if available) or
/persistfs (if available).

You can also use any user-visible local storage device (/tmp/mnt/* or /D).
Also you can mount a network share and use it.

NOTE (IMPORTANT!): Do not forget to do "sync" after each write into flash
memory partition or local storage device.

Manually mounting NFS share

mkdir /mntpoint
mount -o nolock ip-address:/path/to/dir /mntpoint

NOTE: You can also mount NFS/SMB shares via STB menu (go to "Sources",
press "POP UP MENU" RC button, choose "Add network folder").

Access from network to STB storage devices

Sigma Designs platforms:

All storage devices (USB HDD, USB flash drive, etc) attached to the STB are
automatically exported by the STB to network via SMB and FTP protocols, and
can be accessed from network via:
   FTP: ftp://stb-ip-address
   SMB: \\stb-ip-address

Boot process

Sigma Designs platforms:

See here:
   http://files.dune-hd.com/sdk/doc/html/dune_boot_process.html

Running some code automatically on STB boot

Sigma Designs platforms:

Create the folder /config/boot/ and put executable files (e.g. shell
scripts) into it. All executable files in this folder will be automatically
launched by Dune on boot. (More exactly, "root" process will launch these
executables on boot, before starting "shell".)

Be careful: if these executables hang up or do other bad things, STB may
become unusable (and emergency settings reset may be needed).

Terminating Dune GUI

Sigma Designs platforms:

1. Put the STB into "software standby" mode by pressing "POWER" RC button.
2. Terminate Dune GUI processes:
   killall root shell

NOTE: Killing just "shell" process is not enough, as "root" process will
automatically restart it.

Log files

Most log files are written into /tmp/run/ and /tmp/.

Linux kernel log messages are written into /var/log/messages (and are also
accessible via "dmesg").

Android platforms:

Android logs are available in standard way via "logcat" command.

Built-in HTTP server

The "httpd" process (simple HTTP-server based on busybox) listens on TCP
port 80 and serves incoming HTTP requests on this port.

Relevant locations in the filesystem:

   /tmp/www
         WWW root folder. Static files /tmp/www/path/to/file are accessible
         as:
            http://stb-ip-address/path/to/file

   /tmp/www/cgi-bin
         Folder where CGI executables can reside. Executable CGI files
         /tmp/www/cgi-bin/path/to/cgi-exe are accessible as:
            http://stb-ip-address/cgi-bin/path/to/cgi-exe

Sigma Designs platforms:

By default, the HTTP server listens on all network interfaces of the STB
and is accessible not only via the loopback interface (using 127.0.0.1 IP
address) but also via real network interface (using real IP address (e.g.
Ethernet) of the STB). If if it desired to limit the HTTP server to listen
on the loopback interface only, it can be configured using a custom HTTP
server configuration file (see below).

During STB boot, the HTTP server is launched by "root" process (note, this
may take place before the STB has IP address from DHCP server), using the
following command:
   /usr/sbin/httpd -h /tmp/www

It is possible to customize the behavior of the HTTP server by creating
"/etc/httpd.conf" configuration file. The file should be created before the
HTTP server is launched (or HTTP server should be restarted after
creating/changing the configuration file). An appropriate place where this
can be done is a boot script in "/config/boot/" directory (see "Running
some code automatically on STB boot" section) or
"/firmware/config/start.sh" in the custom firmware, see "Custom boot
script" section here:
   http://files.dune-hd.com/sdk/doc/html/dune_custom_firmware.html

See here for additional information about HTTP server and "httpd.conf" file
format:
   http://files.dune-hd.com/sdk/doc/html/httpd.html

Modifying files in root filesystem

Sigma Designs platforms:

The root filesystem (/) is a RAM-disk, whose content is initialized on
Linux kernel boot (the initial RAM-disk content is part of Linux kernel
image).

In runtime, it is possible to apply any modifications to the root
filesystem.

These modifications will be stored in RAM and will be lost on
STB reboot.

If you want to preserve the modifications on STB reboots, you can put the
code which applies these modifications into autostart-on-boot scripts (see
"Running some code automatically on STB boot".

Modifying files in read-only /tango filesystem

Sigma Designs platforms:

The /tango filesystem (aka /tango3, also contains /firmware and
/firmware_ext folders) is read-only CRAMS filesystem. So it is impossible
to directly modify its content.

In runtime, it is possible to apply temporary modifications to this
filesystem using "bind mount". Examples:
1) Replacing a single file:
      mount --bind /tmp/shell /firmware/bin/shell
2) Replacing the entire folder (with all subfolders and files):
      mount --bind /tmp/skin /firmware/skin
3) Adding modifications to certain folder:
      cp -a /firmware/config /tmp/firmware_config
      echo "..." >/tmp/firmware_config/some_file
      mount --bind /tmp/firmware_config /firmware/config

These temporary modifications will be lost on STB reboot.

If you want to preserve the modifications on STB reboots, you can put the
code which applies these modifications into autostart-on-boot scripts (see
"Running some code automatically on STB boot".

NOTE: the presence of such "bind mounts" may prevent /tango from unmounting
and thus lead to firmware upgrade function to fail with an error. If you
are affected by this, either first remove all bind-mounts before performing
firmware upgrade, or use "emergency firmware recovery" procedure (which
works before /tango is mounted and before autostart-on-boot scripts are
launched).

Alternatively, you can build you own version of /tango CRAMFS filesystem
and write it directly into the flash memory of the STB. For more
information on this, see "Extracting and overwriting tango filesystem
image" section.

Extracting and overwriting tango filesystem image

Sigma Designs platforms:

NOTE: This instruction correponds to 86xx platforms.

To extract /tango CRAMFS filesystem image from the flash memory of the STB,
perform the following commands on the STB:
   # For models based on SMP8670:
      dd if=/dev/nblock8 of=/path/to/tango.cramfs
   # For models based on SMP8674 and SMP8672:
      cp /app/tango.cramfs /path/to/tango.cramfs

To modify the /tango CRAMFS filesystem image, perform the following
commands on a Linux PC:
   mkdir /path/to/modified-tango-dir
   mount --loop /path/to/tango.cramfs /tmp-dir
   cp -a /tmp-dir/* /path/to/modified-tango-dir/
   umount /tmp-dir
   # here, do modifications in modified-tango-dir
   mkfs.cramfs -b 4096 /path/to/modified-tango-dir /path/to/tango.cramfs

To write the modified /tango CRAMFS filesystem image back to the flash
memory of the STB, perform the following commands on the STB:
   fuser -mk -9 /tango
   umount /tango
   # For models based on SMP8670:
      dd if=/path/to/tango.cramfs of=/dev/nblock8
   # For models based on SMP8674 and SMP8672:
      losetup -d /dev/loop0
      mount -o remount,rw /app
      cp /path/to/tango.cramfs /app/tango.cramfs
      umount /app
   sync
   reboot

Creating custom firmware images

Sigma Designs platforms:

See here:
   http://files.dune-hd.com/sdk/doc/html/dune_custom_firmware.html

General requirements for custom code running on STB

- Avoid writing to flash memory too often. It is generally recommended to
  ensure that writing to flash memory is performed not often than ~100
  times per day in average in typical end user's scenarious. So, when
  needed, accumulates changes in RAM (or in RAM-disk) and delay writing
  them to flash memory till a suitable moment.

- When writing to flash memory, avoid unneeded writes: if there are good
  chances that the new data is the same as the old data, first compare the
  new data and the old data and skip overwriting the old data if they are
  equal.

- When writing to flash memory, try to do 'sync' as soon as possible, to
  ensure that changes are flushed into the hardware and will not be lost on
  STB reboot or power-off.

- Note that writing to flash memory (or 'sync' command which flushes
  possibly previously buffered changes in flash memory) may cause short (up
  to 1 sec) freezes of various STB activities. In particular, playback may
  freeze. So, when possible, try to delay writes to flash memory to a
  suitable moment. E.g., when writing to flash memory is needed during
  playback, it may be reasonable to delay it till playback stop or channel
  switch.

- Avoid writing too much data into /config (/mnt) partition. This partition
  is not big and it may contain other files besides of your files.

- When writing into /config (/mnt) or /flashdata partitions, be prepared
  that there may not be enough space in these partitions (in case when
  there are other files stored there besides of your files). When possible,
  try to handle failed writes in as robust way as possible.

- When customizing /tango, avoid putting too much extra stuff into
  /firmware folder, and use firmware_ext when reasonable. When preparing
  for firmware upgrade, the system copies the content of /firmware folder
  (but not /firmware_ext folder) into /tmp (RAM-disk), and if there is too
  much stuff there, the available RAM may be exhausted. So, everything that
  is not needed during firmware ugrade, is better to put into /firmware_ext
  rather than /firmware.

- When running background processes and doing extra mounts (especially
  bind-mounts), take into account possible influence on firmware upgrade.
  During firmware upgrade, the system needs to unmount /tango partition; if
  this fails for some reason (e.g. some bind-mount is blocking this), the
  firmware upgrade will fail.

- When running background processes, take into account that their CPU and
  RAM consumption may have influence on other processes running on the STB
  (especially if your background processes run concurrently with web
  browser, or concurrently with native Dune UI). When possible, try to
  minimize CPU and RAM consumption of background processes. When
  reasonable, start background processes using "nice" (e.g. "nice -n 19
  /path/to/your/exe"). When reasonable, shutdown your processes when they
  are not needed.

Debugging tools

Sigma Designs platforms:

GDB and GBD server:
   http://files.dune-hd.com/sdk/misc/gdb.867x
   http://files.dune-hd.com/sdk/misc/gdbserver.867x
   http://files.dune-hd.com/sdk/misc/gdbserver.864x

strace:
   http://files.dune-hd.com/sdk/misc/strace.86xx

tcpdump:
   http://files.dune-hd.com/sdk/misc/tcpdump.86xx.tar.gz

DSF file for launching custom Linux code

The following DSF file allows to run an arbitrary executable/shell-script
w/o the need to use telnet/SSH access to the STB, directly from the native
Dune UI.

http://files.dune-hd.com/sdk/misc/dune_service_exec.dsf

Put this file onto a USB flash drive and "launch" it on the STB (go to
"Sources" menu, navigate into the USB flash drive, choose the file, and
press "ENTER" RC button). It will check for "dune_exec" executable file in
the same directory where the DSF file is located, and execute it.

Launching executables from user storages on Android platforms

Android platforms mount user storages with "noexec" mount flag (for
security reasons), which means that executable files on these storages can
not be directly executed.

To fix this problem, for example, the following command can be used (should
be executed under root user -- i.e. in telnet/ADB session on Realtek
Android platforms, or in telnet session on Amlogic Android platforms):

   mount -o remount,noexec `readlink /tmp/mnt/D`

Or the following utility DSF file can be used (does the same):

   http://files.dune-hd.com/sdk/misc/dune_service_android_main_storage_allow_exec.dsf

The effect is preserved till STB reboot.