Differences between revisions 31 and 41 (spanning 10 versions)
Revision 31 as of 2018-01-16 21:46:27
Size: 4479
Editor: ?RainerDorsch
Comment: Added desktop environment section with Gnome on Wayland
Revision 41 as of 2021-12-28 13:05:43
Size: 5565
Editor: ?RainerDorsch
Comment: Bullseye installed flawless on a microSD card
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
## page was renamed from ArmHardFloatPort/CuBox-i
Line 9: Line 10:
The Cu``Box-i uses U-Boot as a bootloader. As of 2014-03-09, upstream provides [[https://github.com/rabeeh/u-boot-imx6.git|a git tree]] based on U-Boot 2013.10. A port of upstream U-Boot support to 2014.01 (the version in jessie/sid) is available [[https://github.com/vorlonofportland/u-boot.git|here]] and was included in the Debian package u-boot 2014.04-1 (see: Bug:741127). The Cu``Box-i uses [[U-boot|U-Boot]] as a bootloader, and is supported by the U-Boot version in Debian 9/Stretch onwards.
Line 15: Line 16:
The Cu``Box-i should have basic support with the armmp linux kernel (3.16+) in Debian Jessie, including serial console, usb, ethernet, mmc, HDMI, eSATA and ir receiver. To enable additional features, you may need to explore one of the following options:

 * Install a kernel from jessie-backports, stretch, sid or experimental.
 * Apply the [[http://www.home.arm.linux.org.uk/~rmk/cubox/|enablement patches]] to your linux source.
 * Build a kernel from the [[https://github.com/SolidRun/linux-linaro-stable-mx6.git|SolidRun 3.10 stable kernel branch]].
 * Use a pre-built binary kernel image from Solid``Run, available [[http://download.solid-run.com/pub/solidrun/cubox-i/|here]]. (Note: these kernels are based on a Linux 3.0 Android BSP.)
The Cu``Box-i is supported by the armmp linux kernel (4.9+) in Debian Stretch including serial console, usb, ethernet, mmc, HDMI, eSATA and ir receiver.
Line 23: Line 19:
Starting from Debian 8.0, the cubox-i and hummingboard are supported through the official [[https://www.debian.org/releases/stable/armhf/ch02s01.html#armhf-armmp-supported-platforms|debian installer]]. Be prepared to attach a serial console to your cubox-i/hummingboard, because the installer does not output messages on the HDMI interface. Starting from Debian 8/Jessie, the cubox-i and hummingboard are supported through the official [[https://www.debian.org/releases/stable/armhf/ch02s01.en.html#armhf-armmp-supported-platforms|debian installer]].
Line 25: Line 21:
In the default configuration after rebooting from the installer the serial console is not(!) enabled. To enable execute  * For Debian stable, instructions for pre-build images can be found in the [[https://www.debian.org/releases/stable/armhf/ch05s01.en.html#boot-installer-sd-image|official documentation]] of the Debian Installer.
 * Daily images of the Debian Installer are also available for:
  * [[https://d-i.debian.org/daily-images/armhf/daily/netboot/SD-card-images/|netboot]] installation
  * [[https://d-i.debian.org/daily-images/armhf/daily/hd-media/SD-card-images/|hd-media]] installation
Line 27: Line 26:
Be prepared to attach a serial console to your cubox-i/hummingboard, because the installer does not output on the HDMI interface. This can be done for example by installing [[DebianPkg:screen|GNU Screen]] and launching:
Line 28: Line 28:
 echo 'T0:23:respawn:/sbin/getty -L ttymxc0 115200 vt100' >> /etc/inittab screen /dev/ttyUSB0 115200
Line 30: Line 30:

The serial console is available both in the installer and after rebooting into a newly installed (buster) system.
Line 33: Line 36:
On Buster Gnome on Wayland works out of the box. It is important to boot the kernel with the cma=... parameter set, e.g. cma=256M. On Debian 10/Buster [[DebianPkg:GNOME]] defaults to Wayland and works out of the box. Still it is important to boot the kernel with the cma=... parameter set, e.g. cma=256M:
{{{
# echo 'setenv bootargs ${bootargs} cma=256M' | tee /etc/flash-kernel/ubootenv.d/cma && flash-kernel
}}}
Line 37: Line 43:
I added the cma=... parameter by == Ethernet HW Errata ERR004512 ==
ERR004512 results in a risk of ethernet RX FIFO overrun on the i.MX6 chip in the Cubox-i.

A solid description of the issue and workarounds implemented in the Linux kernel is given at
[[https://boundarydevices.com/i-mx6-ethernet/|Boundarydevices]]

Good news is that is seems that Debian buster contains at least the most relevant patches. But even with these patches, it is required to enable flow control on the switch which connects to the Cubox-i. With flowcontrol I saw bandwidths of around 400 MBit/s for TX and 600 MBit/s for RX with Debian buster (measured by iperf). With Debian stretch I saw that enabling flow control also removes the overflows and increases the measured bandwidth, but it was lower than with the buster installation (even with a backports kernel).

With link level flow control enabled, there should be no RX overruns or dropped frames as shown below:
Line 40: Line 54:
rd@xbian:/etc/flash-kernel/bootscript$ diff -u bootscr.cubox-i~ bootscr.cubox-i
--- bootscr.cubox-i~ 2017-07-25 06:58:47.000000000 +0200
+++ bootscr.cubox-i 2018-01-13 17:26:46.983026580 +0100
@@ -29,6 +29,7 @@
fi
 
setenv bootargs @@LINUX_KERNEL_CMDLINE_DEFAULTS@@ ${bootargs} @@LINUX_KERNEL_CMDLINE@@
+@@UBOOT_ENV_EXTRA@@
 
if test -z "${prefix}" ; then
  setenv image_locations '/boot/ /'
rd@xbian:/etc/flash-kernel/bootscript$
rd@home:~$ /sbin/ifconfig eth0
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
        inet6 fe80::d263:b4ff:fe00:325c prefixlen 64 scopeid 0x20<link>
        ether d0:63:b4:00:32:5c txqueuelen 1000 (Ethernet)
        RX packets 133763491 bytes 1832846878 (1.7 GiB)
        RX errors 0 dropped 0 overruns 0 frame 0
        TX packets 11202123 bytes 395662770 (377.3 MiB)
        TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
Line 53: Line 63:
# echo 'setenv bootargs ${bootargs} cma=256M' | tee /etc/flash-kernel/ubootenv.d/cma && flash-kernel rd@home:~$
}}}
Line 55: Line 66:

}}}
Without link level flow control, there may be RX fifo overruns and dropped frames on the cubox ethernet network interface. I have seen bandwidth degradation down to 2 MBit/s on the RX side. I think the latency for retries determines the performance degradation...i.e. on the local networks the bandwidths are still higher if talking to a remote machine on the WAN, severe drops must be expected.

CuBox-i support in Debian

This page exists to collate information about the status of support in Debian for the CuBox-i family of devices by SolidRun (CuBox-i1, CuBox-i2, CuBox-i2Ultra, CuBox-i4Pro).

General information

The CuBox-i devices are a series of small-footprint, always-on computers based on the FreeScale i.MX6 chipset.

Bootloader support

The CuBox-i uses U-Boot as a bootloader, and is supported by the U-Boot version in Debian 9/Stretch onwards.

The CuBox-i U-Boot uses SPL (allowing the same U-Boot image to be used across multiple models), and should be installed to the SD card using the layout described here. Note that this version of U-Boot will also support reading the second-stage bootloader from a FAT filesystem on the first partition of the device; however, since U-Boot also reads its environment from an offset of 384K on the SD card, there is 342K of reserved space at the front of the disk which will be otherwise unused. It is therefore recommended to install U-Boot to the embedded space at the front of the disk, and not to set up a dedicated boot partition on the SD card.

Kernel support

The CuBox-i is supported by the armmp linux kernel (4.9+) in Debian Stretch including serial console, usb, ethernet, mmc, HDMI, eSATA and ir receiver.

Installing Debian

Starting from Debian 8/Jessie, the cubox-i and hummingboard are supported through the official debian installer.

  • For Debian stable, instructions for pre-build images can be found in the official documentation of the Debian Installer.

  • Daily images of the Debian Installer are also available for:

Be prepared to attach a serial console to your cubox-i/hummingboard, because the installer does not output on the HDMI interface. This can be done for example by installing GNU Screen and launching:

screen /dev/ttyUSB0 115200

The serial console is available both in the installer and after rebooting into a newly installed (buster) system.

Desktop Environments

On Debian 10/Buster GNOME defaults to Wayland and works out of the box. Still it is important to boot the kernel with the cma=... parameter set, e.g. cma=256M:

# echo 'setenv bootargs ${bootargs} cma=256M' | tee /etc/flash-kernel/ubootenv.d/cma  && flash-kernel

See also cma entry for the Wandboard

Ethernet HW Errata ERR004512

ERR004512 results in a risk of ethernet RX FIFO overrun on the i.MX6 chip in the Cubox-i.

A solid description of the issue and workarounds implemented in the Linux kernel is given at Boundarydevices

Good news is that is seems that Debian buster contains at least the most relevant patches. But even with these patches, it is required to enable flow control on the switch which connects to the Cubox-i. With flowcontrol I saw bandwidths of around 400 MBit/s for TX and 600 MBit/s for RX with Debian buster (measured by iperf). With Debian stretch I saw that enabling flow control also removes the overflows and increases the measured bandwidth, but it was lower than with the buster installation (even with a backports kernel).

With link level flow control enabled, there should be no RX overruns or dropped frames as shown below:

rd@home:~$ /sbin/ifconfig eth0
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::d263:b4ff:fe00:325c  prefixlen 64  scopeid 0x20<link>
        ether d0:63:b4:00:32:5c  txqueuelen 1000  (Ethernet)
        RX packets 133763491  bytes 1832846878 (1.7 GiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 11202123  bytes 395662770 (377.3 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

rd@home:~$ 

Without link level flow control, there may be RX fifo overruns and dropped frames on the cubox ethernet network interface. I have seen bandwidth degradation down to 2 MBit/s on the RX side. I think the latency for retries determines the performance degradation...i.e. on the local networks the bandwidths are still higher if talking to a remote machine on the WAN, severe drops must be expected.

Further info