Hi Wolfgang, On Tue, Sep 13, 2011 at 2:47 AM, Wolfgang Denk <w...@denx.de> wrote: > Dear Simon Glass, > > In message > <capnjgz3kzjoagjfkpkxqp+-jnztyecuaetlz0nvgzv1f-xu...@mail.gmail.com> you > wrote: >> >> I would love to, yes. To some extent there is a bit of this already, >> at least for specific subsystems. Clearly the fdt would work better if >> we could just hand U-Boot the fdt and say 'init yourself'. It would >> then scan the tree and init all the drivers for all active devices. > > No, it would definitely not do that. > > U-Boot shall not initialize all possible available devices, but always > only those that it needs itself to perform it's task, which usually is > just to load and start an OS. It makes no sense to initialize all > network interfaces (and eventually wait for the link to come up), to > initialize all attached disk drives (and wait for them to spin up) or > to scan the whole USB bus and initialize all attached devices when we > don't need any of these to boot the OS. > > Suchinitializations shall always be done on demand only, i. e. when a > command is run that accesses any such device.
Yes thanks for pointing that out. I am really thinking of the init sequence in board_init_r() where we init NAND, MMC and the like. So yes it makes no sense to blindly init everything we can find. The fdt can provide a list of available options for each device type (although in practice often it will provide only one option, perhaps with multiple instances). > >> However, we can achieve most of the aims using something along the >> lines of what I have proposed, where the existing call (say to >> nand_init()) can look up the fdt for its node, and then get the >> information it needs. The only really difference is the explicit >> hard-coded call to nand_init, rather than a general purpose routine to >> find a nand node and then locate a driver for it. > > I can;t parse that. Why cannot nand_init() do exactly what you > suggest, i. e. find a nand node and then locate a driver for it? > OK, by then it will probably be something like driver_init("nand") or > the like, but that's just a detail. That's certainly the current approach, yes. It does work well I think, and has the virtue of being simple, with minimal changes required to code. > >> To some extent that way of doing things would invert the way U-Boot >> currently works. It would also introduce questions about dealing with >> multiple devices of the same type (e.g. two different i2c controllers >> (not just instances) or driving two displays. These sorts of things >> are tricky in U-Boot at the moment. > > Keep in mind that devices are always accessedonly on demand, so you > will have the needed information which device needs to be opened. Yes, that's true and we mustn't do anything which blurs or weakens that link. When I think of multiple LCD support for example, while there is hardware support for it, do we have a need for it? Sometimes this sort of thing is a solution looking for a problem. Yes it would be easier to implement this feature with a unified driver model, but... On the other hand I think serial could benefit from a unified driver model quite nicely :-) > >> So overall I think a unified driver model is a separate problem, and >> one that we should discuss and perhaps move forward on separately. > > Agreed. OK good. There seem to be a lot of different activities going on, as Graeme says in the other thread. Regards, Simon > > 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: w...@denx.de > If you want strict real-time behavior, run in the real time schedu- > ling class. But there are no seatbelts or airbags; main(){for(;;);} > can hard hang your system. -- Bart Smaalders > _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot