HCL:Turris Omnia
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.