Driver Model Conversion

This page includes a few notes on the status of the conversion of U-Boot to driver model.

Purpose

U-Boot originally had a pretty ad-hoc device driver system. While some subsystems have their own framework (e.g. mmc, block devices, stdio), others are implemented as bare function calls to be provided by whichever driver shows up. This limits us to one driver of a particular type (e.g. you cannot have USB2 and USB3 ports at the same time as they use different drivers).

Driver model aims to provide a consistent model for drivers and the platform data / device tree information needed by drivers to instantiate devices. In particular:

• Hierarchical, allowing a device to have children and parents
• Replaces #define CONFIGs with board-supplied platform data or device tree
• Devices organized by class, e.g. I2C, SPI, LCD
• Efficient implementation, suitable in principle for pre-relocation and SPL
• Devices are known very early but are only activated ('probed') when used
• More scalable as the U-Boot code base grows

Background

Driver model started as a university project in 2012. After some simplifications and adjustments, patches were developed from mid 2013 and it was committed to mainline U-Boot in early 2014.

Marek Vasut's original email in 2010

Marek Vasut's Presentation in 2012

Project Overview of original work 2012

Simon Glass's Presentation in 2013

README describing how it works from early 2014 mainline implementation

U-Boot Mini Summit talk on driver model at ELCE 2014

Embedded Linux Conference 2015 talk on driver model (PDF and video). Also see link to paper

Status Late April 2017

Mainline status:

• About 60 uclasses available, covering most subsystems
• Support is provided for driver model in both U-Boot proper (before and after relocation) and SPL
• Sandbox, Tegra, Exynos, Sunxi/Allwinner, i.MX, Freescale, all ARMv8, OMAP3, Zynq, Raspberry Pi, Rockchip, x86, Atmel and a few others are using driver model

Patches posted (in brackets is the branch at u-boot-dm.git):

• SATA, SCSI

Other things in the works

• PHY

Suggestions for uclasses that people could do:

• Ethernet PHY
• MTD (add proper operations)

See here for the original documentation discussing each subsystem.

-- SimonGlass - 30th April 2017