Just received your Ten64? Update your firmware (v0.8.10 / 2022-03-15)

Ten64’ s built in the initial production run were shipped with the ‘v0.8’ firmware.

The first firmware update (v0.8.5) includes:

  • Introduction of ‘legacy’ mode toggle for Gigabit Ethernet ports and SFP+, see PHY management / ethernet link status in the documentation.

  • Support for gigabit SFPs. Currently requires flashing a different BL2 binary but no further user configuration will be required.

  • Update recovery firmware

    • Improvements to bare metal appliance store (note: due to schema change, ‘RTM’ firmware is no longer compatible with the live registry)
      • Able to fetch manipulator scripts automatically
      • Set locale and default ‘WAN’ interface for cloud-init appliances (among other settings)
      • Set legacy/managed mode correctly for each appliance/distribution (most distributions require legacy mode for SFP, some require legacy mode for 1GBASE-T as well)
    • Add some missing packages (most notably, u-boot envtools/fw_setenv/fw_printenv)
  • Device Tree: remove broken RTC alert interrupt and change RTC compatible string to “epson,rx8035” explicitly, as drivers which are not aware of the RX8035 will not properly interpret the ‘oscillator stop’ bit. (Requires dkms/update for distributions, TODO, patch here)

  • U-Boot: fix setting of RTC time using the ‘date’ command

  • U-Boot: support booting from SATA drives attached to a PCIe controller (not recommended and not default at this stage, U-Boot has issues working with SATA drives after a warm reboot)

Version v0.8.6 adds:

  • Fix deployment of openSUSE from baremetal-deploy
  • baremetal-deploy will not set environment variables (for legacy network modes) if the U-Boot environment appears to be empty or corrupted
  • ./flash.sh (when flashing from recovery) will prompt you to reset the U-Boot environment to default

Version v0.8.7 updates the recovery image to fix a driver issue with the real time clock (Epson RX-8035) and oscillator stop errors. You should no longer need to do a ‘date reset’ in U-Boot after flashing the firmware.

Version v0.8.8 includes kernel 5.10 based versions of the recovery firmware, OpenWrt for NAND and a workaround for errors seen when writing large amounts of data to SD cards.

Version v0.8.9 includes a performance enhancement for the default network configuration (DPL), device tree fix for kernel 5.15 and improvement to the set-wan command in Recovery

Version v0.8.10 incorporates changes for NAND based OpenWrt. If you are not using OpenWrt from NAND, there is no need to upgrade.

We expect the next major firmware release (v1.0) to update to U-Boot 21.07 among others.

v0.8.10 (2022-03-15) download links

The best way to flash the firmware package is to use the recovery firmware. Alternatively, you can write the sdcard image to a card and start your Ten64 in sd-boot mode.

Please see “Firmware Update” in the manual for flashing instructions.


  1. Turn on Ten64, boot into recovery mode from menu
  2. Set your outgoing network interface with set-wan ethX (note: best to choose an interface other than eth0, which is setup as LAN by default)
  3. Download and flash:
root@recovery000afa2424xx:/tmp# curl https://archive.traverse.com.au/pub/traverse/ls1088firmware/firmware-builds/branches/v0.8.10/492260694/firmware-v0.8.10-492260694.tar.xz -O
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 54.4M  100 54.4M    0     0  9937k      0  0:00:05  0:00:05 --:--:-- 11.6M

Note: older recovery firmware versions may have issues downloading due to LetsEncrypt certificate chain issue. If this happens, append -k to the curl command line

root@recovery000afa2424xx:/tmp# tar -Jxf firmware-v0.8.10-492260694.tar.xz
root@recovery000afa2424xx:/tmp# cd firmware-v0.8.10-492260694/
root@recovery000afa2424xx:/tmp/firmware-v0.8.9-413571944# ./flash.sh
Unlocking bl2 ...
Erasing bl2 ...
Unlocking bl2 ...

Writing from arm-trusted-firmware/build/ten64/debug/bl2_qspi.pbl to bl2 ...
Unlocking bl3 ...
Erasing bl3 ...
Unlocking bl3 ...

Writing from arm-trusted-firmware/build/ten64/debug/fip.bin to bl3 ...
Unlocking mcfirmware ...
Erasing mcfirmware ...
Unlocking mcfirmware ...

Writing from qoriq-mc-binary/ls1088a/mc_10.20.4_ls1088a.itb to mcfirmware ...
Unlocking dpl ...
Erasing dpl ...
Unlocking dpl ...

Writing from dpaa2/dpl/eth-dpl-all.dtb to dpl ...
Unlocking dpc ...
Erasing dpc ...
Unlocking dpc ...

Writing from dpaa2/dpc/dpc.0x1D-0x0D.dtb to dpc ...
Unlocking devicetree ...
Erasing devicetree ...
Unlocking devicetree ...

Writing from dtb/fsl-ls1088a-ten64.dtb to devicetree ...
Unlocking recovery ...
Erasing recovery ...
Unlocking recovery ...

Writing from recovery.itb to recovery ...
Do you wish to reflash the OpenWrt-NAND version (do not say "y" if you are currently using it) [y/n] y
ubiformat: mtd9 (nand), size 113246208 bytes (108.0 MiB), 864 eraseblocks of 131072 bytes (128.0 KiB), min. I/O size 2048 bytes
libscan: scanning eraseblock 863 -- 100 % complete
ubiformat: 864 eraseblocks have valid erase counter, mean value is 11
ubiformat: flashing eraseblock 274 -- 100 % complete
ubiformat: formatting eraseblock 863 -- 100 % complete
Do you wish to reset the U-Boot environment to default? [y/n] y
Unlocking ubootenv ...
Erasing ubootenv ...
Warning: Bad CRC, using default environment
1 Like

Oops, the download URL I posted pointed to the previous release - it has been updated.

This version has a U-Boot version of:

U-Boot 2020.07-rc1-gb47b96d4 (Jun 22 2021 - 04:09:02 +0000)

The recovery firmware does not have an embedded version as such (which we will try and fix), but can be identified by:

# uname -a
Linux recoveryXXXXXXXXXX 5.4.61 #0 SMP PREEMPT Tue May 4 06:47:13 2021 aarch64 GNU/Linux
# opkg info muvirt-appstore
Package: muvirt-appstore
Version: 0.4.2-1

Firmware v0.8.6 is out, this rolls in two updates to the recovery firmware and a prompt to reset the U-Boot environment from ./flash.sh:

Do you wish to reset the U-Boot environment to default? [y/n] y
Unlocking ubootenv ...
Erasing ubootenv ...
Warning: Bad CRC, using default environment

(This actually configures U-Boot to reset and save the environment on the next boot)

There are no changes to the other firmware components such as U-Boot or ATF

U-Boot version:

U-Boot 2020.07-rc1-gb47b96d4 (Jun 25 2021 - 01:09:32 +0000)

Recovery is now versioned as well:

 ten64-recovery v0.8.6, 326919195_2021-06-24

Firmware v0.8.7 updates the recovery firmware, integrating a fix to the real time clock driver where the ‘oscillator stop’ flag was not correctly cleared when the clock was updated from a ‘invalid’ state (e.g the first time you powered on a Ten64 out of the box).

There should be no need to run date reset in U-Boot as has been advised for the previous two releases.

There are no other changes.

U-Boot version:

U-Boot 2020.07-rc1-gb47b96d4 (Jul 07 2021 - 00:43:32 +0000)

Recovery version:

 ten64-recovery v0.8.7, 332215009_2021-07-06

There is some work in the background to update U-Boot to 21.07, which should improve distribution compatibility (e.g by implementing the EFI secure boot protocol). I will try to upstream as much as possible in the process.

Firmware v0.8.8 is out, this includes:

  • The new kernel 5.10 based recovery firmware
  • The kernel 5.10 based OpenWrt NAND image
  • A workaround for SD card timeout experienced when writing large amounts of data
  • Updated the U-Boot environment/settings to work with the DPAA2 MC firmware versions 10.29 and later. At the moment MC 10.20.4 remains the bundled firmware version.

If your system is running happily, there is no urgency in updating to this.

You might want to update your device tree at the very least to resolve SD card timeout issues:

curl https://archive.traverse.com.au/pub/traverse/ls1088firmware/firmware-builds/branches/v0.8.8/393201825/components/fsl-ls1088a-ten64.dtb -O

mtd erase devicetree && mtd write fsl-ls1088a-ten64.dtb devicetree
Unlocking devicetree ...
Erasing devicetree ...
Unlocking devicetree ...

Work continues on updating the U-Boot version for the “1.0” firmware, a test branch will be coming soon.

1 Like

Firmware v0.8.9 includes:

  • Update to the default DPL (data plane configuration) so that incoming traffic is spread across all CPU cores (see this thread for more information)
  • Includes a device tree fix for kernel v5.15 and later, a redundant interrupt declaration for gpio-keys was causing a kernel oops/stack trace to be printed on boot
  • Also fixed the device-tree compatible string causing OpenWrt not to apply correct defaults for Ten64
  • set-wan in recovery now attempts to remove ethernet interfaces from bridges (e.g the default br-lan). Thanks to @russm for the patch!

v0.8.9 (2021-11-22) download links

@mcbridematt Two questions.

  1. Would it be possible to include uudecode in recovery system? This would allow to transfer firmware over minicom. Useful when no network available.
  2. How to check firmware version after upgrade?

@wrobell openssl included in the recovery image can encode/decode base64…

echo aXQncy1hIG1lLCBiYXNlNjQhCg== | /usr/bin/openssl enc -base64 -d

but the serial line is going to be slooow - at 115200 baud you’re looking at over an hour for the complete firmware bundle. if you have a way to transfer on a USB stick or something like that it’ll be much less painful.

1 Like

@russm Thanks for the tip. I used SSD, which I put into Ten64 recently. :slight_smile: But one day I might not have any of USB/SSD options available :slight_smile:

@mcbridematt Is it possible to keep lv disks configs after kernel upgrade? I’ve just upgraded muvirt’s kernel and apparently all my vmdata have gone… which subtrees needs to be kept when flashing a new sysupgrade?

Yes, partitions outside /boot and / should be preserved.
If you look at the partition table for your disk with parted, is the LVM and swap still there?

Unfortunately @mcbridematt lscpi didn’t show the SATA controller… so I could only see them going recovery mode… I posted on another thread here that disabling power saving in the grub config could potentially solve this as that enables the sata driver… though UUID could possibly change too… so not really sure If that would work out…
In the end I opted for upgrading k3os with an upgraded k3s (1.23.4) and making a clean install… Btw, k3os will be no longer maintained by the community as rancher was acquired by SUSE… kind of like CoreOS with Redhat back in the day… Are you aware of any other opensource alternative for the future kind of like Proxmox that would suite ten64 harware?