Ten64 Firmware v0.9.0 (Testing branch)

Ten64 Forum Ten64 specific software (μVirt, recovery)
1

After a very long time, I am pleased to announce the release of Ten64 firmware v0.9.0.

This firmware is intended as a stepping stone to an eventual “1.0” release. It is not being marked as “stable” yet as there is still more work to do.

The key change is an update to U-Boot 2023.07-rc2 (vs 2020.07 in the current series), which brings:

  • U-Boot’s new standard boot system
    This replaces the previous script based distroboot system and is much more robust. The previous Ten64 firmware releases contained a lot of fine tuning to distroboot which is no longer necessary. Aside from EFI, there is the possibility of using Verified Boot for Embedded and other methods (syslinux/extlinux).

  • Compatibility with major Linux distributions is improved as U-Boot now implements the TCG2 (TPM) EFI protocol, meaning “shim” wrapped boot-loaders (seen on Fedora and Ubuntu) will work without problems.
    We can’t do full UEFI secure boot yet :frowning: A new TPM chip is required for full secure boot, a retrofit option may be available for current Ten64 boards later in 2023

  • A single device tree source for both U-Boot and operating system. In other words, the device tree blob used by U-Boot is the same that is passed to Linux/FreeBSD/etc.
    The devicetree partition on the flash is no longer used. It will be repurposed for device tree overlays

These three changes solve many of the interoperability issues affecting the Ten64 until now. There is still some other issues to solve (like the DPAA2<->IOMMU setup) but this solves many of them.

The focus of this specific release is on disk-based distributions (Debian,Fedora,openSUSE,OpenWrt armsr,Ubuntu). It can boot OpenWrt-NAND but this is currently outside the new “standard boot” system.

If you want to boot straight into OpenWrt-NAND, use these U-Boot commands to set it as the default:

setenv bootcmd 'run bootcmd_openwrt_nand'
saveenv

On next restart, U-Boot will proceed to boot OpenWrt.

Other planned features for coming v0.9.x releases are device tree overlay support, and firmware updates via distribution standard mechanisms (e.g fwupdate)

Features not yet supported

  • 1.2GHz CPU speed: 1.2GHz CPU binaries are generated, but the firmware does not change the CPU voltage yet.
  • DPAA2 VFIO/passthrough: This firmware includes DPAA2/MC Firmware 10.37. Changes to kernel and/or qemu are required to get passthrough working on more recent versions. You can try downgrading to MC Firmware 10.20.

How to download and install
You can download the v0.9.0 release from https://archive.traverse.com.au/pub/traverse/ls1088firmware/firmware-builds/releases/v0.9.0/

It is recommended to do the flash from the recovery firmware.
Some older recovery firmware versions have TLS certificate trust issues downloading from archive.traverse.com.au . You may want to use another method to transfer the firmware file, or [carefully!] bypass certificate verification (curl -k -O …)

These new firmware releases also come with a self-extracting installer - ten64-firmware-update-v0.9.0.bin

root@recovery000afa242d95:/tmp# sh ten64-firmware-update-v0.9.0.bin
Extracting ten64 update
Unlocking bl2 ...
Erasing bl2 ...
Unlocking bl2 ...
....

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
...

Do you wish to reset the U-Boot environment to default? [y/n] y
Unlocking ubootenv ...
Erasing ubootenv ...

# Do a reboot
/sbin/reboot

On the first boot, U-Boot will write a clean copy of it’s environment variables to flash and reset. Do not interrupt this process.

Menu Change
The boot menu behaviour has been changed.
U-Boot will proceed to the bootcmd by default.
To bring up the boot options menu, press the “s” key at the prompt below:
Autoboot in 10 seconds, press 's' to stop and bring up the boot menu

image

This will bring up the boot options menu:
image

4 Likes
2

Hi Matt,

I upgraded my ten64 to v0.9.0 and it boots successfully into my Gentoo installation. However I noticed that the fan control is not working any more, which used to work OK as soon as the “traverse-sensors” modules were loaded.

I investigated a little bit, and I get the impression, that the controllers should be in U-boots working FTD. When I issue “dm tree” on the U-boot console, emc1704@18, emc1813@4c and pac1934@11 are missing, only emc2301@2f is listed. As a consequence, linux does not find these controllers.

I also noticed, that U-boot now logs “TEN64 mc_fixup_board_dpc start: 0x00000083e0f00000” before booting the management complex, which it did not before. But later on, right before entering the linux kernel, it logs “fdt_fixup_board_enet: ERROR: fsl-mc node not found in device tree (error -9)”. U-boot (“dm tree” command) lists the device as /soc/fsl-mc , so it should be found.

I will attached some logs from the actual upgrade-session, stay tuned.

Greets from Germany, Andreas

Edit: OK, I understand the forum restricts message size, so the whole log does not fit (not even in three posts). But I have them, just in case you may want me to lookup some details.

5

Hi Andreas,

Yes, the FDT is missing some of the sensors compared to the last release. This U-Boot uses an FDT based on the Linux kernel version, where we are not allowed to add bindings for devices that aren’t in the official schema yet.

The fan controller binding also changed for the new fan driver I wrote, which U-Boot shares the code with. It will probably change again when it is eventually up-streamed.
(I think I will just update traverse-sensors to have this version)

I need to figure out a way to handle them. For compliance purposes (SystemReady) we need to hide any bindings that aren’t in the device tree schema. so there might be a variable that controls when they are shown.

You can ignore those messages. They were for troubleshooting issues during development where different FDT blobs were being passed.
The second error message is caused due to the device tree already been processed by U-Boot. Before the bootflow system this only happened just before hand off to Linux.

I am planning to do another release near the end of July. I will be on vacation for the next few weeks.

6

Have a nice holiday!

The unit is a little bit loud now, but works perfectly OK otherwise, I just banned it from my desktop to the server rack :slight_smile:

Greets, Andreas

7

New release out in the testing branch: v0.9.1

Changes:

  • Device Tree Overlay support in U-Boot. This allows you to modify the device tree passed to the operating system without re-compiling U-Boot or the entire Ten64 device tree. I have wanted to turn this on for a while but it always broke something else :frowning:
    It’s working now, see the Device Tree Overlay page in the manual on how to use it.
    Feedback is much appreciated, as the extension system in U-Boot needs to be reworked to fit with standard boot.
  • 1200MHz/0.9V support added back to U-Boot
  • U-Boot will apply a backwards compatibility overlay for the old emc2301 driver. I will not bother anyone with a new driver until it can be upstreamed. Unfortunately this overlay will only be applied for EFI boot. I think I can find a more generic method that will work with all boot methods.
  • All other sensor bindings have been added back to the device tree.

The updated U-Boot is now compatible with many distribution installers (ISO images). You can install Debian, Fedora and openSUSE from their arm64 installer ISOs, but some tweaks are required. See the distribution installer application note in the manual for more information.

A patch was recently posted to fix the DPAA2 IOMMU issue, so these extra steps may not be needed for much longer :slight_smile:

1 Like