What?Why?How?

When?

U-Boot Driver Model

Marek Vasut

July 12, 2012

Marek Vasut U-Boot Driver Model

What?Why?How?

When?

Outline

1 What?

2 Why?

3 How?

4 When?

Marek Vasut U-Boot Driver Model

What?Why?How?

When?

What?

I What is the driver model?

I Why do we need it?

I How will we implement it?

I When will it be deployed?

Marek Vasut U-Boot Driver Model

What?Why?How?

When?

What is the driver model?

I An unified framework for device drivers

Is

A way of writingdevice drivers

Provides

Softwarerepresentation ofhow hardware isconnected

Organises

The system intree-like structure

Marek Vasut U-Boot Driver Model

What?Why?How?

When?

What is the driver tree?

I A tree-like structure

I Nexus nodes representbusses

I Leaf nodes represent devices

CPU bus

CPU clock logic

NAND controller

NAND flash chip

DDR DRAM

I2C bus 0

RTC

EEPROM 0

EEPROM 1

Marek Vasut U-Boot Driver Model

What?Why?How?

When?

What is the driver tree?

I A tree-like structure

I Nexus nodes representbusses

I Leaf nodes represent devices

CPU bus

CPU clock logic

NAND controller

NAND flash chip

DDR DRAM

I2C bus 0

RTC

EEPROM 0

EEPROM 1

Marek Vasut U-Boot Driver Model

What?Why?How?

When?

What is the driver tree?

I A tree-like structure

I Nexus nodes representbusses

I Leaf nodes represent devices

CPU bus

CPU clock logic

NAND controller

NAND flash chip

DDR DRAM

I2C bus 0

RTC

EEPROM 0

EEPROM 1

Marek Vasut U-Boot Driver Model

What?Why?How?

When?

Why do we need it?

U-Boot . . .

I is full of #ifdef – #else – #endif constructs

I is mostly configured by changing #define-d values

I has hard time supporting multiple devices of the same type

I We have per-device-type ad-hoc implementationsI More such ad-hoc hacks are starting to appear

I all in all simply doesn’t scale anymore

Marek Vasut U-Boot Driver Model

What?Why?How?

When?

How will we implement it?

The implementation breaks down into several stages:

I Move drivers from arch/ to drivers/

I EASY

I Introduce the driver model core mechanisms.

I HARD A A

I Convert drivers onto the new driver model.

I EXTRA HARD A A A

I Introduce early mallocator for early drivers.

I MEDIUM A

Marek Vasut U-Boot Driver Model

What?Why?How?

When?

Introduce the driver model core mechanisms

Driver’s point of view:

I U-Boot must be aware of driver’s existence

Marek Vasut U-Boot Driver Model

What?Why?How?

When?

Introduce the driver model core mechanisms

Driver’s point of view:

I U-Boot must be aware of driver’s existence

struct driver attribute ((section(driver list)))

Marek Vasut U-Boot Driver Model

What?Why?How?

When?

Introduce the driver model core mechanisms

Driver’s point of view:

I U-Boot must be aware of driver’s existence

struct driver attribute ((section(driver list)))

I Driver’s instances must make the U-Boot aware of them

Marek Vasut U-Boot Driver Model

What?Why?How?

When?

Introduce the driver model core mechanisms

Driver’s point of view:

I U-Boot must be aware of driver’s existence

struct driver attribute ((section(driver list))) {char name[LENGTH];

int (*bind)(struct instance *i);

int (*probe)(struct instance *i);

int (*reloc)(struct instance *i);

int (*remove)(struct instance *i);

int (*unbind)(struct instance *i);

};I Driver’s instances must make the U-Boot aware of them

Marek Vasut U-Boot Driver Model

What?Why?How?

When?

Introduce the driver model core mechanisms

Driver’s point of view:

I U-Boot must be aware of driver’s existence

I Driver’s instances must make the U-Boot aware of them

I Driver must be able to create multiple independent instancesof itself

Marek Vasut U-Boot Driver Model

What?Why?How?

When?

Introduce the driver model core mechanisms

Driver’s point of view:I U-Boot must be aware of driver’s existenceI Driver’s instances must make the U-Boot aware of themI Driver must be able to create multiple independent instances

of itself

struct driver instance {uint32 t flags;

struct instance i;

};struct instance {

const struct driver info *info;

struct instance *bus;

void *private data;

struct successor block *succ;

};Marek Vasut U-Boot Driver Model

What?Why?How?

When?

Introduce the driver model core mechanisms

U-Boot’s point of view:

I Must be able to track driver instances

I Must be able to use driver instancesI Concept of cores

I Special single-instance kind of driverI Tracks driver instances of certain classI Provides unified access API for class of devicesI Driver binds with the core using bind() function

Marek Vasut U-Boot Driver Model

What?Why?How?

When?

Introduce the driver model core mechanisms

Programmer’s point of view:

I Is presented with a (virtual) root bus

I Must create the bindings between devices and busses:

struct driver info {char name[LENGTH];

void *platform data;

}

struct instance *

driver bind(struct instance *parent,

const struct driver info *di));

Marek Vasut U-Boot Driver Model

What?Why?How?

When?

Review of the workage

I The programmer calls driver bind()

I Driver is located

I Instance is allocated and initialized

I bind() is called

The result:

I The particular core is aware of the driver’s instance

I BUT, the driver is not yet running

Marek Vasut U-Boot Driver Model

What?Why?How?

When?

Starting the driver

I Driver is started by calling driver activate()

I This is handled by the core upon first use of the driver

I This in turn calls it’s .probe() function

I That’s when the hardware is initialized!

Marek Vasut U-Boot Driver Model

What?Why?How?

When?

Summary

Pros:

I Lazy initialization of devices

I Results in faster boot times

I No ad-hoc hacks to allow multiple devices

I Much less #define-d values

I Model close to Linux kernel’s one

Cons:

I The bootloader is a bit bigger

I But it’s mostly static data in ROM

I Slightly more memory is used

Marek Vasut U-Boot Driver Model

What?Why?How?

When?

Problems

I Drivers that need to be initialized very early

I Introduce early stack-based mallocatorI Allocate only, stub free()

I Relocation of driver’s internal data

I Introduce reloc() call

I Writing the whole binding is bothersomeI Per-CPU generic bindingsI Per-architecture generic bindingI . . .

Marek Vasut U-Boot Driver Model

What?Why?How?

When?

When?

I During the next 6 months

I That’s two releases away

Marek Vasut U-Boot Driver Model

What?Why?How?

When?

What next?

I Review and discuss the design

I Update the prototype code

I Let it all get mainline

I Enjoy the result

Marek Vasut U-Boot Driver Model

What?Why?How?

When?

The End

Thanks to:I You

I For your attention!

I Pavel Herrmann, Viktor Krivak, Tomas HlavacekI For being a great team on this project

I Graeme RussI For coming up with wild and crazy ideas

I The DENX crewI For being good friends, helpful advisors and constructive critics

I Wolfgang DenkI For countering my crazy ideas with real-world examples and for

tolerating my flubs

Marek Vasut U-Boot Driver Model

What?Why?How?

When?

Questions?

?

Contact: Marek Vasut <marex@denx.de>Mailing list: u-boot-dm@lists.denx.de

Marek Vasut U-Boot Driver Model