From mboxrd@z Thu Jan 1 00:00:00 1970 From: Wolfgang Denk Date: Tue, 13 Sep 2011 11:47:34 +0200 Subject: [U-Boot] [RFC PATCH v2 1/6] fdt: ARM: Add device tree control of U-Boot (CONFIG_OF_CONTROL) In-Reply-To: References: <1315865067-1443-1-git-send-email-sjg@chromium.org> <1315865067-1443-2-git-send-email-sjg@chromium.org> <201109130510.22185.marek.vasut@gmail.com> Message-ID: <20110913094734.E595A1408E93@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 Simon Glass, In message 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. > 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. > 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. > 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. 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 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