[U-Boot] [RFC] Driver model

[Marek Vasut <marek.vasut@gmail.com>]

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