Dne Po 20. září 2010 12:54:06 Wolfgang Denk napsal(a): > Dear Marek Vasut, > > In message <201009201205.41037.marek.va...@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 mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
