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):
Other things in the works
Suggestions for uclasses that people could do:
- Ethernet PHY
- MTD (add proper operations)
See
here for the original documentation discussing each subsystem.
--
SimonGlass - 19th December 2017
