• arm
• imx6

Note: this is slightly old information (last material modification 2015-02-02 01:45:25 by IanLepore)

FreeBSD on Freescale i.MX6 systems

The Freescale i.MX6 family of SoCs is available in single, dual, and quad core versions. These SoCs are showing up in a growing number of development boards and small low power computer systems. FreeBSD has basic support for many of these boards and systems, including the following:

• Wandboard

• CuBox i

• HummingBoard

Support

Development of FreeBSD i.MX6 support is active and ongoing. For the latest information or help with anything, please send an email to freebsd-arm@freebsd.org.

What works

FreeBSD 11 is where active development happens for i.MX6 systems and ARMv7 in general. The FreeBSD 10-stable branch is also kept up to date, with changes being merged to it typically 30-60 days after they've been committed to 11.

The following device drivers are available:

• Serial console
• uarts [tested up to 1mbaud]
• i2c
• USB 2.0
• SPI
• SD Card (iMMC support not verified yet)
• Gigabit ethernet (hw limits throughput to 40MB/s, driver currently achieves 26MB/s)
• Basic CPU thermal management (frequency is scaled back if temperature limits are exceeded)
• Hardware floating point
• Audio
• Video / framebuffer
• SATA

What still needs to be done

Lots of device drivers still need to be written, including:

• PCIe
• CCM (clocks, work is in progress)
• PMU (power managment)

Building FreeBSD

The Crochet script supports Wandboard and is probably the easiest way to get started with FreeBSD on i.MX6. It creates images from scratch, ready to copy to an sdcard.

The i.MX6 boot process

The i.MX6 chip has a small on-chip rom and a small amount of on-chip sram. The rom code is able to boot from several different device types, based on how pullup and pulldown resistors are connected to some gpio pins. Most systems are set to boot from SD card. The on-chip rom tries to load a boot program from offset 1024 (the start of the third sector) on the SD card. If it can read from the card it loads the boot program into the internal sram, verifies that it's a valid boot program, and begins executing it.

Most i.MX6 systems use U-Boot as the boot program. Recent versions of U-Boot are split into a small first-stage loader called SPL and a main boot program. The SPL program for i.MX6 determines what type of chip it is (solo, dual, or quad) and how much ram it has, and sets up the main ram timing registers. It then loads the main U-Boot program from a fixed sector number on the SD card into ram and begins executing it. The fixed location on the SD card for the main U-Boot program can vary, but is usually in the neighborhood of 40-60K into the card. Following the main U-Boot program is the area of the card where U-Boot stores the saved environment data. In general, the first megabyte of the SD card is reserved for boot stuff.

The main U-Boot program can be configured with many different options for loading a kernel from SD card, USB drives, SATA drives, or the network. When booting FreeBSD the usual process is to have U-Boot start ubldr (a version of loader(8) tailored for use with U-Boot), and ubldr loads and starts the kernel. To use ubldr, U-Boot must be configured with the CONFIG_API option, and unfortunately, most i.MX6 system vendors do not include that option when they build U-Boot. For that reason, we generally end up building our own copy of U-Boot to use with FreeBSD. If you ever try to start ubldr from U-Boot and it exits with a status of 0xnnBADAB1 that's a sign that U-Boot was built without the API option.

Recently the customized versions of U-Boot have been turned into FreeBSD ports and packages. You can simply "pkg install u-boot-wandboard" and everything you need to get U-Boot onto an SD card is installed for you in /usr/local/share/u-boot, including a README file that tells you how to install the file(s) onto the SD card.

When an i.MX6 system has several models, such as a dual processor and quad processor model, a single version of U-Boot can typically boot both types of system. U-Boot will create environment variables that name the type of chip and system, and these can be used by U-Boot env scripts to create a filename for the FDT data, such as 'env set fdt_file ${soc}-${board}.dtb' which might set, for example, imx6q-wandboard.dtb, causing ubldr to load the correct dtb file and pass it to the kernel.

FreeBSD/arm CUBOX-HUMMINGBOARD SD card images status on Hummingboard-i2

Legend

*1: crash at u-boot stage. Maybe latest u-boot does not support Hummingboard-i2. sanpei use old u-boot which is included 11.0-RELEASE.

From sysutils/u-boot-cubox-hummingboard/pkg-descr:

>As of this writing,the changes in this fork have not been rolled back into upstream U-Boot.

replace u-boot script

*2 GENERIC kernel could not mount root partition

mmc1: CMD8 failed, RESULT: 1
mmc1: ACMD41 failed, RESULT: 4

temporary add below to /boot/loader.conf.local and put sdma firmware, sdma-imx6q-to1.fwo on /boot/kernel

hw.regulator.disable_unused=0

and at boot time in loader, you must below paramators.

set sdma-imx6q-to1.fwo_load="YES"
set sdma-imx6q-to1.fwo_type="firmware"

Related Bug: FreeBSD Bugzilla – Bug 237466

*3 can't use upper USB port