[U-Boot] [RFC] Driver model

[U-Boot] [RFC] Driver model

[Marek Vasut]

Hi,

most of the readers here probably noticed, there are various forks of U-Boot 
bootloader floating around the net. The development model there is quite closed 
and certainly not community driven, on the other hand, they have neat driver 
model.

As for U-Boot, there currently is no driver model. Therefore I'd like to start a 
discussing on this topic so we can converge towards a reasonable result.

My few points:

* Start with ethernet subsystem
It seems to be quite ready for conversion of this scale. Besides it'd be easy to 
prove multiple instances of ethernet device work with the driver model.

* Create an universal driver model:
The driver will have usual .probe function, which will have some argument of 
type "void *" to it's driver data. This way we can pass it's base address for 
example instead of #defining it. Very similar to linux kernel.

* We need some "device tree"
To know, what driver is where and where are it's driver data etc.

* Get rid of static data in drivers, switch to dynamic allocation
So these wont interfere with multiple instances of the same driver.

Cheers

[U-Boot] [RFC] Driver model

[Wolfgang Denk]

Dear Marek Vasut,

In message <201009201205.41037.marek.vasut@gmail.com> you wrote:
> 
> most of the readers here probably noticed, there are various forks of U-Boot 
> bootloader floating around the net. The development model there is quite closed 
> and certainly not community driven, on the other hand, they have neat driver 
> model.

You are speaking about barebox, right? [I am not aware of another fork
with a driver model.]

> * Start with ethernet subsystem
> It seems to be quite ready for conversion of this scale. Besides it'd be easy to 
> prove multiple instances of ethernet device work with the driver model.

Indeed ethernet seems to make sense; eventually followed by serial, as
this will quickly show some of the challenges (i. e. driver support in
the restricted environment before relocation). Block devices (IDE,
SDCard/MMC, USB, eventually also NAND etc.) could need some
unification as well.

> * Create an universal driver model:
> The driver will have usual .probe function, which will have some argument of 
> type "void *" to it's driver data. This way we can pass it's base address for 
> example instead of #defining it. Very similar to linux kernel.

Instead of picking out a single function, we should rather discuss the
whole interface. I guess the stating point would be the current BB
implementation?

> * We need some "device tree"
> To know, what driver is where and where are it's driver data etc.

Using the DT for run-time configuration of U-Boot would be especially
interesting. Assume: a single U-Boot image for all - say - OMAP3
boards...

> * Get rid of static data in drivers, switch to dynamic allocation
> So these wont interfere with multiple instances of the same driver.

This might be a challange. Keep in mind that some drivers (console,
eventually I2C / SPI, MMC/SDcard, NAND, ...) might be needed before
relocation to RAM.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
At the source of every error which is blamed on the computer you will
find at least two human errors, including the error of blaming it  on
the computer.

[U-Boot] [RFC] Driver model

[Marek Vasut]

Dne Po 20. z??? 2010 12:54:06 Wolfgang Denk napsal(a):
> Dear Marek Vasut,
> 
> In message <201009201205.41037.marek.vasut@gmail.com> you wrote:
> > most of the readers here probably noticed, there are various forks of
> > U-Boot bootloader floating around the net. The development model there
> > is quite closed and certainly not community driven, on the other hand,
> > they have neat driver model.
> 
> You are speaking about barebox, right? [I am not aware of another fork
> with a driver model.]

I wanted to avoid saying it right away.
> 
> > * Start with ethernet subsystem
> > It seems to be quite ready for conversion of this scale. Besides it'd be
> > easy to prove multiple instances of ethernet device work with the driver
> > model.
> 
> Indeed ethernet seems to make sense; eventually followed by serial, as
> this will quickly show some of the challenges (i. e. driver support in
> the restricted environment before relocation). Block devices (IDE,
> SDCard/MMC, USB, eventually also NAND etc.) could need some
> unification as well.
> 
> > * Create an universal driver model:
> > The driver will have usual .probe function, which will have some argument
> > of type "void *" to it's driver data. This way we can pass it's base
> > address for example instead of #defining it. Very similar to linux
> > kernel.
> 
> Instead of picking out a single function, we should rather discuss the
> whole interface. I guess the stating point would be the current BB
> implementation?
> 
> > * We need some "device tree"
> > To know, what driver is where and where are it's driver data etc.
> 
> Using the DT for run-time configuration of U-Boot would be especially
> interesting. Assume: a single U-Boot image for all - say - OMAP3
> boards...

This looks very cool. I thought about this and I came to a further idea:
* Make "minimal" u-boot that'd be independent of DTree
* Upon setting variable "fdt" to an address of the DTree, enable remaining 
components of uboot

The second point would allow booting a platform in case the DTree was faulty. Or 
we can have a known-good DTree and a variable that'd allow to override it, that 
might be even better.
> 
> > * Get rid of static data in drivers, switch to dynamic allocation
> > So these wont interfere with multiple instances of the same driver.
> 
> This might be a challange. Keep in mind that some drivers (console,
> eventually I2C / SPI, MMC/SDcard, NAND, ...) might be needed before
> relocation to RAM.
> 
> Best regards,
> 
> Wolfgang Denk

[U-Boot] [RFC] Driver model

[Wolfgang Denk]

Dear Marek Vasut,

In message <201009241737.27335.marek.vasut@gmail.com> you wrote:
>
> > Using the DT for run-time configuration of U-Boot would be especially
> > interesting. Assume: a single U-Boot image for all - say - OMAP3
> > boards...
>
> This looks very cool. I thought about this and I came to a further idea:
> * Make "minimal" u-boot that'd be independent of DTree
> * Upon setting variable "fdt" to an address of the DTree, enable remaining 
> components of uboot
>
> The second point would allow booting a platform in case the DTree was faulty. Or 
> we can have a known-good DTree and a variable that'd allow to override it, that 
> might be even better.

We will probably need something like that anyway - the "minimal
configuration" being largely what is running before relocation, the
"full configuration" when we have full access to normal resources.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
There were meetings. There were always meetings. And they were  dull,
which is part of the reason they were meetings. Dull likes company.
                                    - Terry Pratchett, _Making_Money_

[U-Boot] [RFC] Driver model

[Albert ARIBAUD]

Le 24/09/2010 19:35, Wolfgang Denk a ?crit :
> Dear Marek Vasut,
>
> In message<201009241737.27335.marek.vasut@gmail.com>  you wrote:
>>
>>> Using the DT for run-time configuration of U-Boot would be especially
>>> interesting. Assume: a single U-Boot image for all - say - OMAP3
>>> boards...
>>
>> This looks very cool. I thought about this and I came to a further idea:
>> * Make "minimal" u-boot that'd be independent of DTree
>> * Upon setting variable "fdt" to an address of the DTree, enable remaining
>> components of uboot
>>
>> The second point would allow booting a platform in case the DTree was faulty. Or
>> we can have a known-good DTree and a variable that'd allow to override it, that
>> might be even better.
>
> We will probably need something like that anyway - the "minimal
> configuration" being largely what is running before relocation, the
> "full configuration" when we have full access to normal resources.
>
> Best regards,
>
> Wolfgang Denk

Stop me if I'm wrong, but basically this would imply that u-boot be 
built with support for the largest possible device combination, thus be 
rather big, right? I hope the ability to trim it down u-boot to a 
minimum is retained, though, i.e. be able to choose between a 
one-size-fits-all binary that will run on anything *or* a tight fit that 
will run only on a given platform with minimal footprint (or anything 
in-between, actually).

Amicalement,
-- 
Albert.

[U-Boot] [RFC] Driver model

[Wolfgang Denk]

Dear Albert ARIBAUD,

In message <4C9CE432.7060100@free.fr> you wrote:
>
> Stop me if I'm wrong, but basically this would imply that u-boot be
> built with support for the largest possible device combination, thus be
> rather big, right? ...

Probably yes - similar to how Linux kernels are configured today by
default, i. e. one kernel image being able to run on all (or at least
a wide range of) boards of the same architecture, or even of a number
of similar / compatible architectures.

>                ... I hope the ability to trim it down u-boot to a
> minimum is retained, though, i.e. be able to choose between a
> one-size-fits-all binary that will run on anything *or* a tight fit that
> will run only on a given platform with minimal footprint (or anything
> in-between, actually).

Of course. We will always allow customized, board specific
configurations that can be kept as small as possible if they don't
need this feature.

But if you look at current trends with SoC and board manufacturers, it
would be really great if we could have some image that covers more
than just one or two boards.


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
It is practically impossible to teach good programming style to  stu-
dents that have had prior exposure to BASIC: as potential programmers
they are mentally mutilated beyond hope of regeneration.   - Dijkstra

[U-Boot] [RFC] Driver model

[Albert ARIBAUD]

Le 24/09/2010 20:59, Wolfgang Denk a ?crit :

> Of course. We will always allow customized, board specific
> configurations that can be kept as small as possible if they don't
> need this feature.

Good.

> But if you look at current trends with SoC and board manufacturers, it
> would be really great if we could have some image that covers more
> than just one or two boards.

This is understandable too; I just wanted to make sure there was a choice.

Thanks for the clarification!

Amicalement,
-- 
Albert.