From mboxrd@z Thu Jan 1 00:00:00 1970 From: Wolfgang Denk Date: Mon, 20 Sep 2010 12:54:06 +0200 Subject: [U-Boot] [RFC] Driver model In-Reply-To: <201009201205.41037.marek.vasut@gmail.com> References: <201009201205.41037.marek.vasut@gmail.com> Message-ID: <20100920105406.17F62157D71@gemini.denx.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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.