From: Wolfgang Denk <wd@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [RFC] Driver model
Date: Mon, 20 Sep 2010 12:54:06 +0200 [thread overview]
Message-ID: <20100920105406.17F62157D71@gemini.denx.de> (raw)
In-Reply-To: <201009201205.41037.marek.vasut@gmail.com>
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.
next prev parent reply other threads:[~2010-09-20 10:54 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-20 10:05 [U-Boot] [RFC] Driver model Marek Vasut
2010-09-20 10:54 ` Wolfgang Denk [this message]
2010-09-24 15:37 ` Marek Vasut
2010-09-24 17:35 ` Wolfgang Denk
2010-09-24 17:47 ` Albert ARIBAUD
2010-09-24 18:59 ` Wolfgang Denk
2010-09-24 19:32 ` Albert ARIBAUD
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100920105406.17F62157D71@gemini.denx.de \
--to=wd@denx.de \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox