HCL:Turris Omnia

Jump to: navigation, search

The Turris Omnia is a router, originally shipping with OpenWrt.

Technical data

  • Marvell Armada 385 SoC
    • dual-core ARMv7 CPU @ 1.6 GHz
  • 2x USB
  • 2x PCIe, 1x PCIe/mSATA
  • 5x GbE (LAN), 1x GbE (WAN), 1x SFP

Manual installation

The vendor's U-Boot does not support XHCI, so that the two USB ports cannot be used for booting. That leaves eMMC and mSATA as local boot options.

The shipping U-Boot, unlike earlier prototypes, enables a ~two minute watchdog timer when entering U-Boot. This requires the /dev/watchdog or /dev/watchdog0 device to be closed once, for example by wdctl, to avoid a system reset.

Building an upstream kernel

Use mvebu_v7_defconfig and enable CONFIG_BTRFS_FS.

Installation to USB

The vendor's U-Boot does not support XHCI and therefore does not recognize any USB devices on either of the two USB ports. Still you can place your rootfs onto USB.

The vendor's OpenWrt kernel has USB drivers built as modules and no initrd, so you cannot directly boot a USB rootfs with it. An easy solution is to build an upstream kernel yourself with those drivers built-in and to copy it to the eMMC's /boot directory (e.g., zImage-next).

Note: In linux-next.git next-20160318 kernel only USB 3.0 devices work.

Partition your USB disk with GPT or MBR. Create a partition for the rootfs and extract an openSUSE-Tumbleweed-JeOS.armv7-rootfs.armv7l-XXX.tbz tarball. Then boot similar to this (derived from bootargs and mmcboot variables):

setenv bootargs 'console=ttyS0,115200 root=/dev/sda1 rootfstype=ext4 rootwait rw'
btrload mmc 0 0x01000000 boot/zImage-next @
btrload mmc 0 0x02000000 boot/dtb @
bootz 0x01000000 - 0x02000000

Note: As always, "/dev/sda1" is unsafe as it may become, e.g., /dev/sdb1 when an mSATA SSD or a second USB storage device is connected.

You could save those commands in a U-Boot environment variable, otherwise you will need to re-type them on each boot.

Installation to mSATA

Unless you have another device with mSATA port, you may find it difficult to set up the SSD.

You will find that OpenWrt does not come with parted, fdisk or gdisk tools for partitioning your /dev/sdX device.

One solution is to boot into openSUSE Tumbleweed, where you can easily install those tools, from USB (cf. above):

setenv bootargs 'console=ttyS0,115200 root=/dev/sdb1 rootfstype=ext4 rootwait rw'
btrload mmc 0 0x01000000 boot/zImage-next @
btrload mmc 0 0x02000000 boot/dtb @
bootz 0x01000000 - 0x02000000

From inside openSUSE verify that /dev/sda is your mSATA card and partition it using gdisk (zypper in gptfdisk). Format your new partition and extract a JeOS rootfs tarball. For now just copy zImage-next and dtb over.

mount /dev/sda1 /mnt
tar xvjf openSUSE-Tumbleweed-JeOS.armv7-rootfs.armv7l-XXX.tbz -C /mnt
cp /boot/zImage-next /mnt/boot/zImage-next
cp /boot/dtb /mnt/boot/armada-385-turris-omnia.dtb
ln -sf zImage-next /mnt/boot/zImage
ln -sf armada-385-turris-omnia.dtb /mnt/boot/dtb

Boot similar to this:

setenv bootargs 'console=ttyS0,115200 root=/dev/sda1 rootfstype=btrfs rootwait rw'
setenv fdtfile armada-385-turris-omnia.dtb
scsi scan
btrload scsi 0:1 0x01000000 boot/zImage-next
btrload scsi 0:1 0x02000000 boot/dtb/$fdtfile
bootz 0x01000000 - 0x02000000

It's beginning to look much more like openSUSE, just lacking an openSUSE kernel still.

Installation to eMMC

In theory you can also replace OpenWrt with openSUSE, optionally backing it up as btrfs snapshot. To do so you'll need to boot from some other root device such as USB or mSATA.

mount /dev/mmcblk0p1 /mnt
btrfs subvolume snapshot /mnt/@ /mnt/root-pre-opensuse
rm -rf /mnt/@/*
tar xvjf openSUSE-Tumbleweed-JeOS.armv7-rootfs.armv7l-XXX.tbz -C /mnt/@
cp /boot/zImage-next /mnt/@/boot/zImage-next
cp /boot/dtb /mnt/@/boot/armada-385-turris-omnia.dtb
ln -sf zImage-next /mnt/@/boot/zImage
ln -sf armada-385-turris-omnia.dtb /mnt/@/boot/dtb

Then on next boot you should boot into openSUSE automatically.

openSUSE kernel

Unlike mvebu_v7_defconfig, the openSUSE kernels build drivers as modules whenever possible. To boot you will need additional driver modules in a ramdisk. There's two easy ways to create such an initrd file. Either use Kiwi (as done for our JeOS SD card images) or boot into the system once without modules and have the initrd be created by dracut. If you zypper up or zypper dup the system for the first time, chances are a new kernel-default package gets installed and generates an initrd; you can force this the easy way by reinstalling the package (zypper in -f kernel-default) or figure out the lengthy dracut command line. Try to boot it like this:

setenv bootargs 'console=ttyS0,115200 root=/dev/sda1 rootfstype=btrfs rootwait rw'
scsi scan
btrload scsi 0:1 0x01000000 boot/zImage
btrload scsi 0:1 0x02000000 boot/dtb/armada-385-turris-omnia.dtb
btrload scsi 0:1 0x03000000 boot/initrd
bootz 0x01000000 0x03000000:$filesize 0x02000000

This resulted in:

Kernel image @ 0x1000000 [ 0x000000 - 0x6f2d78 ]
Wrong Ramdisk Image Format
Ramdisk image is corrupt or invalid

This is for lack of CONFIG_SUPPORT_RAW_INITRD.

With a patched U-Boot the openSUSE 4.8 kernel results in random MAC addresses, whereas a next-20161028 kernel has stable addresses.

Testing U-Boot

The turris/misc.git repository contains a tool sendbeacon that can be used together with U-Boot's kwboot tool to boot U-Boot via UART instead of from built-in SPI flash.

git clone https://gitlab.labs.nic.cz/turris/misc.git
make -C misc/sendbeacon
git clone https://gitlab.labs.nic.cz/turris/turris-omnia-uboot.git -b omnia
cd turris-omnia-uboot
make ARCHV=arm db-88f6820-gp_defconfig

In the U-Boot .config enable CONFIG_MVEBU_BOOTROM_UARTBOOT=y and tweak board/Marvell/db-88f6820-gp/kwbimage.cfg to BOOT_FROM uart.

Make any other changes such as:

  • adding #define CONFIG_SUPPORT_RAW_INITRD in include/configs/db-88f6820-gp.h,
  • tweaking, e.g., mmcboot variable for custom boot commands,
  • commenting out hw_watchdog_init(); in board/Marvell/db-88f6820-gp/db-88f6820-gp.c.
make ARCHV=arm
../misc/sendbeacon/sendbeacon /dev/ttyUSB0

Now power-on or reset the device. Once it prints a line full of "15"s it will exit.

./tools/kwboot -t -B 115200 /dev/ttyUSB0 -b u-boot-spl.kwb

If you encounter xmodem: Bad message, just run the kwboot command again.

After about 23% you should see the U-Boot SPL executing and returning to the bootrom, then continuing to 100% and running the main U-Boot as usual.

See also