Differences between revisions 2 and 40 (spanning 38 versions)
Revision 2 as of 2014-03-10 03:52:20
Size: 2940
Editor: ?SteveLangasek
Comment: document bootloader, kernel status
Revision 40 as of 2019-09-11 16:20:33
Size: 5709
Editor: ?RainerDorsch
Comment:
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
## page was renamed from ArmHardFloatPort/CuBox-i
Line 6: Line 7:
The [[http://cubox-i.com|CuBox-i]] devices are a series of small-footprint, always-on computers based on the Free``Scale i.MX6 chipset. The [[https://www.solid-run.com/freescale-imx6-family/cubox-i/|CuBox-i]] devices are a series of small-footprint, always-on computers based on the Free``Scale i.MX6 chipset.
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 has been submitted for inclusion in the Debian package in 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 11: Line 12:
The Cu``Box-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 [[http://imx.solid-run.com/wiki/index.php?title=Building_the_kernel_and_u-boot_for_the_CuBox-i_and_the_HummingBoard#U-Boot_Upstream|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. The Cu``Box-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 [[http://wiki.solid-run.com/Building_the_kernel_and_u-boot_for_the_CuBox-i_and_the_HummingBoard|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.
Line 15: Line 16:
The i.MX6 chipset should be supported by the upstream Linux kernel at version 3.13 (the current version in jessie/sid as of 2014-03-09), using the armmp kernel flavor available in the Debian archive. However, the device tree definition for the Cu``Box is not available upstream in 3.13. Although the device tree definitions are kernel-independent, they are built as part of the kernel source. To get a kernel for the Cu``Box, you will need to do one of the following:
 * Apply the [[http://www.home.arm.linux.org.uk/~rmk/cubox/hummingboard-cubox-i-v3.13-20140120/|enablement patches]] to your linux 3.13 source.
 * Build a kernel from the [[https://github.com/SolidRun/linux-linaro-stable-mx6.git|SolidRun 3.10 stable kernel branch]].
 * Download a pre-built dtb file for your device from [[http://people.debian.org/~vorlon/cubox-i/|people.debian.org]].
 * Use a pre-built binary kernel image from Solid``Run, available [[http://download.solid-run.com/pub/solidrun/c1/kernel/initial/images/|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 21: Line 18:
Note that while recent Debian kernels will be able to boot on the Cu``Box with the simple addition of the .dtb file, full support for all devices (e.g., video) requires enablement patches which are not yet included in the Linux mainline. == Installing Debian ==
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]].

 * 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

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:
{{{
screen /dev/ttyUSB0 115200
}}}

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

Currently (2019-07-30), it seems that when the installer finished and should boot into the new system it hangs and needs a manual power cycle.

== Desktop Environments ==

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

See also [[https://wiki.debian.org/InstallingDebianOn/Wandboard#cma|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
[[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:

{{{
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 ==
 * Thomas Bechtold's [[https://toabctl.wordpress.com/2016/02/07/installing-debian-stretch-on-a-cubox-i/|blog entry]] about bootstrapping a SD-Card with Debian Stretch for Cubox-4i
 * Gunnar Wolf's [[http://gwolf.org/node/3896|blog entry]] about bootstrapping a Cu``Box-i4
 * Rainer's [[http://bokomoko.de/~rd/Debian/cubox-i-notes.txt|notes]] on bootstrapping a Cu``Box-i4
 * The [[http://www.solid-run.com/community/|CuBox-i Community]]
 * The [[http://wiki.solid-run.com/CuBox-i_Hardware/|CuBox-i wiki]]
 * Armbian by Igor Pečovnik is a Debian-derived [[http://www.armbian.com/hummingboard/|distribution]]

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.

Currently (2019-07-30), it seems that when the installer finished and should boot into the new system it hangs and needs a manual power cycle.

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