Hi Mike, On Thu, Aug 18, 2011 at 11:54 AM, Mike Frysinger <vap...@gentoo.org> wrote: > On Thursday, August 18, 2011 11:59:35 Simon Glass wrote: [snip snip]
> i dont follow. before u-boot gets to command line processing (either the > "bootcommand" env var or user input), little to no hardware should be > initialized, only registered as available. after that, what hardware actually > gets poked is completely user decided at run-time. > > dont want to use usb hardware ? then dont call "usb start". dont want to use > network hardware ? then dont do network commands (i.e. tftp). > > what am i missing ? OK that's not how it is at the moment in some cases, but fair enough. We have been pushing Tegra in that directly as it happens, but certainly there is still a fair amount of mandatory init which should be moved into / called from drivers. >> > arches calling i2c_init() in their arch/*/board.c are broken imo. only a >> > few do it: arm, ppc, m68k. the common "i2c" command already takes care >> > of exposing "i2c reset" for people to init this as necessary, and other >> > arches havent had any troubles that i can see (certainly i know people >> > have used i2c on Blackfin systems from u-boot). >> >> I feel the idea of calling i2c_init() multiple times with a speed >> parameter is not great. Perhaps the function is just misnamed. > > perhaps it is more historical, but that is the current API, and it is already > called multiple times, so it's required to work. i dont think this has been a > big deal so far for driver writers, but that doesnt mean it has to stay this > way. but wrt your requirements, i dont think we need to dive down that rabbit > hole ... just kill off the explicit call to i2c_init() in the arm board.c. Er ok, but I found one in stdio.c! >> > LCDs should only get initialized if it's the splash screen, otherwise i >> > cant think of any reason that hardware would ever get touched. so if >> > you dont want the overhead of programming that hardware, then dont >> > enable splash screen support ? i cant see a situation where you'd >> > enable splash screen support but not actually show the splash screen ... >> >> Well often U-Boot is asked to set up the LCD so that it will work for >> the kernel. There may be a specific power-on init sequence to follow >> even if nothing is actually written to the screen. For example in >> Chrome OS we don't have splash screen support but still init the LCD. > > ruh-roh. i think this is generally considered the wrong way to do things. > the kernel drivers should be able to pick up the hardware and have it work > regardless of what the (possibly brain dead) firmware that came before it did. > relying on the hardware to be in a certain state. it's even better done in > the kernel as there you can do the init asynchronously whereas in u-boot, > everything is single threaded. We can't have a sensible console in U-Boot without keyboard and LCD - for me the splash screen is a separate issue. Yes the single-threaded problem does make it tricky. Am thinking about that problem now. > >> >> To save time, reduce the amount of code executed and thereby improve >> >> security, we are wanting to initialize only some peripherals at the >> >> start. For example we might start up I2C and SC/MMC. >> > >> > this is generally the policy now. init code should only be *registering* >> > the availability of devices. it shouldnt be initializing the actual >> > hardware until requested. >> >> OK then I vote for a framework which understands this and calls driver >> init once (in a lazy fashion when needed if you like). > > each framework should already do that. if there's a specific one you think is > missing, then you should highlight it. > > if you're talking about overhauling/unifying the driver model rather than each > one being open coded, that's a different thing. but i dont think your current > requirements (as i understand them) necessitates such effort. I suppose the ad-hoc nature of drivers means that people miss the 'generally accepted way' that things are supposed to be done. Regards, Simon > -mike > _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
